Stephane Chazelas wrote, on 01 Jul 2021:
>
> 2021-07-01 11:45:40 +0100, Geoff Clare via austin-group-l at The Open Group:
>
> > The GNU implementations (including bash builtins) of the POSIX utilities
> > do it right. Of course, I don't know whether they were already
> > well-behaved in this regard before they were updated to conform to
> > POSIX.2-1992.
> [...]
>
> Note that GNU rm returns failure upon:
>
> touch file && rm -fv file > /dev/full
>
> Which seems to contradict:
>
> The following exit values shall be returned:
>
> 0
> Each directory entry was successfully removed, unless its
> removal was canceled by a non-affirmative response to a
> prompt for confirmation.
>
> >0
> An error occurred.
>
> (the wording suggests failure to write on stdout (or any "error"
> that occurs after the last file was successfully removed) is not
> to be considered an error).
>
> The >0 should probably be moved to the top, or clarify the
> errors (whatever that means, again, is it at the discretion of
> implementor to decide what constitutes an error?) take precedence
> here.
The -v option is only in the Issue 8 drafts. It looks like we missed
the need for a change to the EXIT STATUS section when it was added.
I'd suggest adding to the description of exit status 0:
In addition, if the -v option is specified, information about each
removed file was successfully written to standard output.
> Same goes for many utilities. See expr for instance.
>
> Here, we've been focusing on pwd, where there's less scope for
> argumentation, as the "p" in pwd is for "print". It's less
> obvious for:
>
> if ! rm -vf -- "$file"; then
> ...
> fi
>
> Or:
>
> if expr 1 '<' 2; then...
>
> Where one could argue ignoring the write errors actually adds
> robustness, and not ignoring them can be dangerous (for instance
> allows one to change a script's logic by redirecting its stdout
> to /dev/full or set a low filesize limit).
In the case of rm -v, the list of removals could be important (e.g.
saved for record keeping purposes), so I think rm is right to give a
non-zero exit if there is a write error.
The expr case seems highly unlikely to occur in any real application.
If only the expr exit status is being tested, and the output isn't being
used, the application writer would almost certainly send it to /dev/null.
(Or accept that neglecting to do so is a bug in their application.)
Also, fully robust error handling needs to distinguish between different
non-zero exit statuses when only some of them indicate an error. E.g.:
if expr 1 '<' 2 >/dev/null; then...
would still have a problem if the shell can't find expr because PATH is
wrong, etc. This is a common problem with "lazy" (less than fully
robust) error handling for utilities such as grep and test.
--
Geoff Clare <[email protected]>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
