On 2021-06-28 20:01:03 +0700, Robert Elz via austin-group-l at The Open Group 
wrote:
> if a utility is invoked with any of stdin/out/err closed then what happens
> is very explicitly unspecified in POSIX.   My guess is that that is largely
> because if the utility then opens a file it will be given a fd that
> corresponds to the (or one of the) closed stdin/out/err streams, and truly
> bizarre things are likely to happen - but that kind of issue is not stated
> as the reason, you simply get unspecified behaviour if a utility is
> started that way.

POSIX defines the EBADF error as

  Bad file descriptor. A file descriptor argument is out of range,
  refers to no open file, or a read (write) request is made to a file
  that is only open for writing (reading).

So, if writing to a closed fd yields unspecified behaviour, what
does "refers to no open file" mean?

> austin-group-l@opengroup.org (really Geoff Clare) said:
>   | The error occurred, and because of it the utility did not do what it is
>   | supposed to do.
> 
> That's debatable.   The outcome was not what was desired, but the utility
> did exactly what was required of it, it determined (one assumes for this
> purpose, where this fails truly is an error to be reported) the current
> working directory and printed it, then exited, with no errors reported to
> it.
> 
> You might prefer that it "fflush(stdout); if (ferror(stdout)) ..." but
> there's nothing explicit in the standard that says that it has to do that.

But the standard says "shall write", and knowing that this may or
may not succeed, it is the responsibility of the shell to check
that it has succeeded.

Otherwise, there would be no way to check data integrity with a
shell script.

Note that ISO C has similar wording for fclose(): "The fclose function
returns zero if the stream was successfully closed, or EOF if any
errors were detected." But AFAIK, everyone assumes that it is the
responsibility of the implementation to detect any error.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - 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)

  • Re: utilities and w... Stephane Chazelas via austin-group-l at The Open Group
  • Re: utilities and w... Geoff Clare via austin-group-l at The Open Group
  • Re: utilities and w... Joerg Schilling via austin-group-l at The Open Group
  • Re: utilities and w... Robert Elz via austin-group-l at The Open Group
    • Re: utilities ... Stephane Chazelas via austin-group-l at The Open Group
      • Re: utilit... tg...@mirbsd.org via austin-group-l at The Open Group
        • Re: ut... Vincent Lefevre via austin-group-l at The Open Group
        • Re: ut... Vincent Lefevre via austin-group-l at The Open Group
        • Re: ut... Geoff Clare via austin-group-l at The Open Group
    • Re: utilities ... Vincent Lefevre via austin-group-l at The Open Group
    • Re: utilities ... Robert Elz via austin-group-l at The Open Group
      • Re: utilit... Vincent Lefevre via austin-group-l at The Open Group
        • Re: ut... Philip Guenther via austin-group-l at The Open Group
      • Re: utilit... Robert Elz via austin-group-l at The Open Group
    • Re: utilities ... Geoff Clare via austin-group-l at The Open Group
      • Re: utilit... Stephane Chazelas via austin-group-l at The Open Group
        • Re: ut... Vincent Lefevre via austin-group-l at The Open Group
        • Re: ut... Stephane Chazelas via austin-group-l at The Open Group
        • Re: ut... Vincent Lefevre via austin-group-l at The Open Group
        • Re: ut... Vincent Lefevre via austin-group-l at The Open Group

Reply via email to