zsh-workers
 help / color / mirror / code / Atom feed
From: Stephane Chazelas <stephane@chazelas.org>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [BUG] builtin echo doesn't check write error
Date: Wed, 9 Jun 2021 19:16:17 +0100	[thread overview]
Message-ID: <20210609181617.k5jbq3z37lt7ry5s@chazelas.org> (raw)
In-Reply-To: <CAH+w=7bVY_1Tedy1d1Yy55+XjbNAWdGJvMQ0mU+54+6xpAyoag@mail.gmail.com>

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.

-- 
Stephane


  reply	other threads:[~2021-06-09 18:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09 14:09 Vincent Lefevre
2021-06-09 14:17 ` Vincent Lefevre
2021-06-09 15:33   ` Stephane Chazelas
2021-06-09 15:40     ` Stephane Chazelas
2021-06-09 15:59       ` Stephane Chazelas
2021-06-09 16:13 ` Bart Schaefer
2021-06-09 18:16   ` Stephane Chazelas [this message]
2021-06-10  8:11     ` Vincent Lefevre
2021-06-24  8:47     ` Vincent Lefevre
2021-06-24  9:07       ` Vincent Lefevre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210609181617.k5jbq3z37lt7ry5s@chazelas.org \
    --to=stephane@chazelas.org \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).