Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: [BUG] builtin echo doesn't check write error

Since this message from Stephane got truncated in the archives
before a line starting with "From "


I'm including it entirely below, quoted to avoid this issue.
I've just posted a message

  archived messages with "From " get truncated

about this truncation issue.

Note also about the bug in echo/print/etc., this actually seems
to affect *all* builtins. For instance:

zira% (exec >&-; echo)
zsh: write error: bad file descriptor
zira% (exec >&-; echo >&-)
zira% (exec >&-; print)
zsh: write error: bad file descriptor
zira% (exec >&-; print >&-)
zira% (exec >&-; printf "\n")
zsh: write error: bad file descriptor
zira% (exec >&-; printf "\n" >&-)
zira% (exec >&-; pwd)
zsh: write error: bad file descriptor
zira% (exec >&-; pwd >&-)
zira% (exec >&-; history)
zsh: write error: bad file descriptor
zira% (exec >&-; history >&-)

On 2021-06-09 19:16:17 +0100, Stephane Chazelas wrote:
> 2021-06-09 09:13:42 -0700, Bart Schaefer:
> [...]
> > My (possibly poor) recollection is that this was made this way in part
> > for ports to environments that don't have a /dev/null device
> While that sounds like a very plausible reason for the original
> behaviour whereby "print" would not report any write error,
> that doesn't really tie up with the current behaviour where
> the error is supressed only when print/echo's stdout is
> explicitly closed.
> Why would one write print foo >&- in the first place, other than
> to check whether print reports error or not (and in that regard,
> the behaviour is very misleading)
> From looking at the history, it looks more like:
> 1990 (1.0) echo ignores write failures (by design or not).
> 1999 workers/9129 Peter writes the "print foo >&-" succeeds, no
>      error test case, just documenting the actual behaviour of
>      print ignoring errors (here using >&- as the easiest way to
>      trigger a write error).
> 2002 workers/16503 Clint adds some error messages upon write
>      errors.
> 2002 workers/16556 we realise it breaks the test case above, so
>      Bart removes the error message on EBADF for that test case
>      to pass again. The fact that there's still an error message
>      in (print)>&- looks like an oversight. The error in that
>      case is output by execcmd_exec after print has returned as
>      it tries to fflush stdout again,, not bin_print (you'll
>      notice the error message doesn't mention "print").
> 2011 workers/29845 Peter notices the error is displayed in
>      (exec >&-; print) and adds a test case for it, but I'm not
>      sure he correctly identified why.
> It very much looks like an (multiple) accident of
> implementation.
> POSIX does say that printf/echo should return with a non-zero
> exit status upon error, and stderr be used for diagnostix
> errors as usual. It's not clear to me if implementations are at
> liberty to decide whether a write() error is considered an error
> or not.
> In any case, it would be useful from an error point of view to
> be able to detect when writing fails.

Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Messages sorted by: Reverse Date, Date, Thread, Author