78eadc76d4
The first verifies that echo exits >0 when it encounters an I/O error on its output (this part would have succeeded for a long time). It also verifies the POSIX requirement that when most standard utilities (or perhaps many rather than most) exit(>0) they must write a message to stderr. Our sh's built in echo did not do that (nor does /bin/echo but that's not relevant here). The second demonstrates (on an unfixed built-in echo) a bug reported in private e-mail by Oguz <oguzismailuysal@gmail.com> where once an instance of the built-in echo has detected an I/O error, all later invocations of the built-in echo, with no I/O errors of their own, also exit(1) (the error status on stdout is not cleared, each echo sees the "I/O error occurred" and does exit(1)). In this second sub-test, the "2>&-" on the first echo command is simply an artifact caused by the test harness - the "check" function verifies that exit((>0) requires a message on stderr (and vice versa), but that only applies to most (or many) utilities, echo is one, but sh is not. In the second test, the exit status comes from sh - sh is permitted to write to stderr (via the echo command it runs in this case) and still exit(0). But the check function in the test does not understand that subtlety. So, we simply suppress the stderr message by closing stderr (the first of these two new sub-tests has verified that the message exists).. |
||
|---|---|---|
| .. | ||
| bin | ||
| crypto | ||
| dev | ||
| fs | ||
| games | ||
| include | ||
| ipf | ||
| kernel | ||
| lib | ||
| libexec | ||
| modules | ||
| net | ||
| rump | ||
| sbin | ||
| share | ||
| sys | ||
| usr.bin | ||
| usr.sbin | ||
| Makefile | ||
| Makefile.inc | ||
| README | ||
| h_macros.h | ||
README
$NetBSD: README,v 1.4 2012/05/18 15:36:21 jruoho Exp $ When adding new tests, please try to follow the following conventions. 1. For library routines, including system calls, the directory structure of the tests should follow the directory structure of the real source tree. For instance, interfaces available via the C library should follow: src/lib/libc/gen -> src/tests/lib/libc/gen src/lib/libc/sys -> src/tests/lib/libc/sys ... 2. Equivalently, all tests for userland utilities should try to follow their location in the source tree. If this can not be satisfied, the tests for a utility should be located under the directory to which the utility is installed. Thus, a test for env(1) should go to src/tests/usr.bin/env. Likewise, a test for tcpdump(8) should be in src/tests/usr.sbin/tcpdump, even though the source code for the program is located under src/external. 3. Otherwise use your own discretion.