Re: no exit status available when a command doesn't exist or fails in pipe to grep

[Neil R. Ormos]

Ed Morton wrote:
> Neil R. Ormos wrote:

>> Even adopting that definition of "success"
>> would still not get you the return code from
>> the command, because the effect "our attempt to
>> close() [the command]" appears to be invariant
>> regardless of whether the piped command has
>> failed.

> It will get us the return code of the command if
> we allow it to. Here's what the GNU manual says:

>    In gawk, starting with version 4.2, when
>    closing a pipe or coprocess (input or
>    output), the return value is the exit status
>    of the command

> All I'm suggesting is that gawk do the same
> thing whether it's in POSIX mode or not and I
> think that's reasonable since POSIX doesn't
> define "success"

I fully understand what you're suggesting.

It's inconsistent with the plain meaning of the
POSIX spec.

>> Consider these scripts and results:

> I did but I'm not sure what I'm supposed to get
> out of them.

I explained in detail.  Having been twice ignored,
I won't repeat the mistake.

It is error to rely on gawk's non-zero return
value from close(), when --posix is not specified,
as indicating that the call to close() has failed.
The non --posix return value from close() is
defined in the gawk manual to be "some kind of
error" only when the value is -1.

No matter how useful might be the return code from
the command, the POSIX spec directs that close()
return 0 "if the close was successful [...]
otherwise, it shall return non-zero."  In a
context where the spec ALSO commands that a prior
mechanical action be performed--close the file or
pipe--the plain meaning is that the success being
measured is that of the action, which does not
ordinarily depend on the return code from command
being piped.  Further, the gawk manual offers
example situations in which the call to close()
may itself be considered to be an error, returning
-1 as a result and setting ERRNO.  So the notion
that we somehow don't know what "if the close was
successful" means is a fiction.

But it's Arnold and Andy you have to convince.

If the piped command's return code were supplied
in ERRNO instead of as the return value from
close(), perhaps that would adequately expose the
required information without contravening the
earlier-quoted section of the POSIX spec.