| Age | Commit message (Collapse) | Author |
|---|
|
what it was intended to test.
The intention was to test that src/bin/ps/utf8.c handles embedded NUL bytes
correctly, just as the other tests in the same group test the handling of
various other non-printable characters. But testing that does not work
for multiple reasons. Neither does the shell pass the NUL byte to the
called test program as intended, nor can argv[] in a C program contain
a NUL byte in the middle of an argument, simply because in the C language,
a string is defined to end at the first NUL byte. On top of all that,
even the function mbswprint() that was supposed to be tested terminates
the processing of the multi-byte input string as soon as it encounters
a NUL byte (all of which is correct behaviour).
So this particular subtest was totally bogus and only worked by accident,
for reasons completely unrelated to the intended purpose. I don't think
the test needs to be replaced by anything else. NUL bytes in the middle
of a program argument just aren't a thing in the first place.
Thanks to deraadt@ for asking what the purpose of this test_ps() call was.
|
|
|
|
|
|
|
|
|
|
|
|
^C does not abort `read < /dev/zero', instead it read(2)s indefinitely,
one null byte at a time; bash and ksh93 from ports abort as expected.
Use the new timeout(1) $PROG trick to send ^C after 0.1s, but also
rely on it's -k for the final SIGKILL to stop the busy-looping process.
./th's `time-limit: 1' prints "test timed out (limit of 1 seconds)" but
leaves the process running.
|
|
First try add capturing use cases like the bin/ksh/main.c r1.52 one:
"[...] we would not run the signal trap if,
for example, ^C was pressed and -e was set."
With so many different factors (errexit?, receiving (special) signals,
traps themselves failing/returing non-zero, running child processes?, etc.)
it is very easy to miss subtle behaviour changes during scripting...
|
|
|
|
The ./th perl script always runs -p prog (KSH in Makefile) as the shell,
but cannot signal it other than the optional SIGKILL after `time-limit'.
Implementing time-related signal handling in ./th seems overkill, so always
pass the program as PROG in the environment so it can wrap itself, e.g.
description:
simluate interrupting a script
stdin:
timeout --signal SIGINT --preserve-status -- 1s $PROG -c '
actual test script getting ^C after one second...
'
Avoiding hard-coded programs in tests with PROG allows testing different
shells through `make KSH=/path/to/sh' without changing or adding shell
specific tests.
While here, make -p and -s as mandatory in usage as ./th `die's if they're
not passed (allowing to always just pass -p's argument as PROG).
|
|
|
|
both pass in bash and ksh93 from ports.
our ksh fails for now, so mark them as expected fail.
|
|
both behave the same with our ksh, bash and ksh93 from ports.
|
|
The following three cases behave identical in bash(1), but our ksh
(ksh93 also) fails to run the trap in the last case:
(non-zero exit code is trigger, no redirection)
$ ksh -c 'trap "echo ERR" ERR ; false'
ERR
(failed redirection is trigger, 'echo' was not executed)
$ ksh -c 'trap "echo ERR" ERR ; echo >/'
ksh: cannot create /: Is a directory
ERR
(failed redirection, no execution, trap was NOT triggered)
$ ksh -c 'trap "echo ERR" ERR ; exec >/'
ksh: cannot create /: Is a directory
bash(1) prints "ERR" in all three cases, as expected.
ksh93 behaves like our ksh(1).
In ksh `exec' is a builtin (CSHELL), but also special (SPEC_BI):
$ type alias
alias is a shell builtin
$ type exec
exec is a special shell builtin
Without command and redirection alone, `exec' permanently redirects I/O for
the shell itself, not executing anything; it is the only (special) builtin
with such a special use-case, implemented as c_sh.c:c_exec().
This corner-case is overlooked in exec.c:execute() which handles iosetup()
failure for all commands, incl. builtins.
Exclude c_exec() from the rest of special builtins to ensure it runs the
ERR trap as expected:
$ ./obj/ksh -c 'trap "echo ERR" ERR ; exec >/'
ksh: cannot create /: Is a directory
ERR
Also add three new regress cases covering this; rest keep passing.
OK millert
|
|
very specific behaviour
document this accordingly in the guidelines section of the manpage
ok bluhm@
|
|
* compile the edit utility once
* emit a warning during timeout
|
|
This makes it easier to debug if something fails. Add some ${SUDO}
in a way that this tests runs as root or regular user with and
without SUDO set.
|
|
allowing the actual tests to become less repetitive.
ok bluhm@
|
|
look at these tests: add a comment providing a high-level picture of
what is going on here, such that everyday maintenance can be performed
without going down the rabbit hole of subr.sh and edit.c.
|
|
sequences, but coverage of four-byte sequences was incomplete, which
contributed to the recently fixed ksh(1) emacs.c bug not being found
for some time.
Consequently, add some tests covering
+ valid sequences starting with \0360, \0361, and \0363;
+ incomplete sequences starting with \0360 and \0361;
+ invalid (too low) sequences starting with \0360.
OK anton@
|
|
The incorrectness of this test was exposed by the bugfix
in /usr/src/bin/ksh/emacs.c rev. 1.88 and reported to me by bluhm@.
This is a minimal fix replacing the incorrect test line
with two correct tests involving the same byte.
OK anton@
|
|
okay tb@
|
|
|
|
|
|
|
|
millert's clear-screen change in vi.c -r1.57 it now depends on $TERM
|
|
From Martijn Dekker
|
|
With the pipefail option set, the exit status of a pipeline is 0 if all
commands succeed, or the return status of the rightmost command that
fails. This can help stronger error checking, but is not a silver
bullet. For example, commands will exhibit a non-zero exit status if
they're killed by a SIGPIPE when writing to a pipe. Yet pipefail was
considered useful enough to be included in the next POSIX standard.
This implementation remembers the value of the pipefail option when
a pipeline is started, as described as option 1) in
https://www.austingroupbugs.net/view.php?id=789#c4102
Requested by ajacoutot@, ok millert@
|
|
while using option e.
|
|
fixed. Some tests fail due to missing POSIX compliance as documented
in the readme. Mark them as expected failures.
|
|
framework. Three ed tests are currently failing for unknown reasons.
They are marked as disabled for now.
from Sergey Bronnikov
|
|
Suggested by anton@
|
|
|
|
While the code intended to support both -s NAME and -s SIGNAME, the
tests performed were wrong. Replace convoluted code with less cryptic
conditionals. ok anton@
|
|
Prodded by anton@
|
|
|
|
in the installer.
from tb@
|
|
|
|
the command name is printed in a more logical way for -e without -c.
Adjust the tests accordingly.
Requested by bluhm@.
|
|
OK jca
|
|
No binary change on amd64 and there should be no differences on any
other 64 bit architecture either (because long = int64_t).
ok cheloha, tb
|
|
Previously it was possible to overflow integers while parsing. With this
diff, we support any kind of POSIX-compatible integers for comparisons.
with input by and ok schwarze, ok tb
|
|
|
|
Based on FreeBSD's expr and NetBSD's old regression test suite.
with input by and ok schwarze
|
|
|
|
framework. Three ed tests are currently failing for unknown reasons.
They are marked as disabled for now.
from Sergey Bronnikov
|
|
|
|
|
|
POSIX requires only decimal, octal and hex, tests for the $((x#number))
notation could be useful too.
|
|
descriptive header before each test, inspired by the many others in regress.
|
