---
- branch: MAIN
  date: Tue May 18 21:37:56 UTC 2021
  files:
  - new: '1.6'
    old: '1.5'
    path: src/tests/bin/sh/t_builtins.sh
    pathrev: src/tests/bin/sh/t_builtins.sh@1.6
    type: modified
  id: 20210518T213756Z.c3fedd73f48e80852348a882e2ee9bb2cebb426a
  log: |
    Add two new sub-tests to the echo test case of the t_builtins shell ATF test.

    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)..
  module: src
  subject: 'CVS commit: src/tests/bin/sh'
  unixtime: '1621373876'
  user: kre