Re: utilities and write errors

Robert Elz wrote, on 30 Jul 2021: > > Date:Thu, 29 Jul 2021 10:38:25 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210729093825.GA7847@localhost> > > | Therefore, in the case of pwd, it is crystal clear that "Successful > |

Re: utilities and write errors

Date:Thu, 29 Jul 2021 10:38:25 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20210729093825.GA7847@localhost> This is definitely my last message in this thread (and given your new bug #1492 I believe that you now accept that the current

Re: utilities and write errors

[Catching up after a few days' vacation] Robert Elz wrote, on 25 Jul 2021: > > Date:Thu, 15 Jul 2021 10:19:17 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210715091917.GA13523@localhost> > > For pwd "0 Successful completion"

Re: utilities and write errors

On 2021-07-25 09:16:16 +0700, Robert Elz via austin-group-l at The Open Group wrote: > I say that pwd must write to standard output, but that nothing says that > that write must actually succeed - because there simply is no text that > requires that (if there were, someone would have quoted it by

Re: utilities and write errors

Date:Thu, 15 Jul 2021 10:19:17 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20210715091917.GA13523@localhost> Sorry, I've had other (more useful) things to do than deal with this... | You are looking at the wrong EXIT STATUS wording.

Re: utilities and write errors

Robert Elz wrote, on 13 Jul 2021: > > Date:Tue, 13 Jul 2021 10:18:02 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210713091802.GA28355@localhost> > > Let's rearrange the order of this to make the issues more obvious. > > We'll

Re: utilities and write errors

On 2021-07-13 22:37:55 +0700, Robert Elz via austin-group-l at The Open Group wrote: > We'll start with the EXIT STATUS section of cd: > > 82508 >0 Either the -e option or the -P option is not in effect, and an error > occurred. > 82511 >1 Both the -e and the -P options are in effect, and an

Re: utilities and write errors

Date:Tue, 13 Jul 2021 10:18:02 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20210713091802.GA28355@localhost> Let's rearrange the order of this to make the issues more obvious. We'll start with the EXIT STATUS section of cd: 82508 >0

Re: utilities and write errors

Robert Elz wrote, on 12 Jul 2021: > > Date:Mon, 12 Jul 2021 09:48:33 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210712084833.GA31700@localhost> > > | Together these things constitute a requirement that pwd only exits > |

Re: utilities and write errors

"Robert Elz via austin-group-l at The Open Group" wrote: > The bosh test is not useful though, since it doesn't bother to do > the required output at all ... > > bosh $ echo $PWD $OLDPWD > /tmp/b /tmp/a > bosh $ cd - > bosh $ echo $PWD $OLDPWD > /tmp/a /tmp/b Thank you for the hint, I

Re: utilities and write errors

Date:Mon, 12 Jul 2021 09:48:33 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20210712084833.GA31700@localhost> | That's not the only way. The usual traversal via .., ../.., etc. could | be done, but just storing dev/ino pairs on the

Re: utilities and write errors

Robert Elz wrote, on 09 Jul 2021: > > | The whole > | point of that bit of rationale is that pwd should not write each > | component of the pathname individually as it works them out; > > You'd think so, but that doesn't make a lot of sense, as if the code > is obtaining the path component

Re: utilities and write errors

Geoff Clare via austin-group-l at The Open Group dixit: >Robert Elz wrote, on 05 Jul 2021: >As I said before, there is nothing in the standard that requires pwd >to be written in C. Nor is there anything that requires it to use the >interfaces described in XSH (or their equivalent in another

Re: utilities and write errors

Date:Thu, 8 Jul 2021 10:57:13 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20210708095713.GA24532@localhost> | As Vincent pointed out, you are misinterpreting the standard. "If an | error is detected, output shall not be written to

Re: utilities and write errors

Robert Elz wrote, on 07 Jul 2021: > > Date:Mon, 5 Jul 2021 10:51:04 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210705095104.GA23845@localhost> > > | As I said before, there is nothing in the standard that requires pwd > |

Re: utilities and write errors

On 2021-07-07 00:48:28 +0700, Robert Elz via austin-group-l at The Open Group wrote: > | > Implementor of what? > | Of pwd. > > Who has no idea whether or not buffering is being used. When using stdio, the implementor knows that buffering *may* be used. Thus he needs to call fflush at the

Re: utilities and write errors

Date:Mon, 5 Jul 2021 10:51:04 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20210705095104.GA23845@localhost> | As I said before, there is nothing in the standard that requires pwd | to be written in C. No issue with that, | Nor

Re: utilities and write errors

on here). > | > | Hopefully you will now see sense and agree that equivalent changes should > | be made in NetBSD. > > I have no problem changing the builtin pwd in the NetBSD sh, that's easy > (the builtin echo - but not /bin/echo which is different code) already does >

Re: utilities and write errors

On 2021-07-05 13:53:45 +0700, Robert Elz via austin-group-l at The Open Group wrote: > Once again, buffering exists and is known to exist - and what's more, > the standard actually *required* stdout to be buffered whenever it is > not associated with a terminal (which is no big surprise, as

Re: utilities and write errors

Date:Mon, 5 Jul 2021 00:41:23 +0100 From:Harald van Dijk Message-ID: <88337ff9-c726-c563-4d4f-3fa74d964...@gigawatt.nl> | I was looking at the HTML version. Aside from its search function, you | can find it there under System Interfaces (top left frame), then

Re: utilities and write errors

On 04/07/2021 21:54, Robert Elz wrote: Date:Sun, 4 Jul 2021 19:26:25 +0100 From:Harald van Dijk Message-ID: <40fc0b0c-364f-8ff8-0613-a76c887d4...@gigawatt.nl> | P.S.: The fact that the underlying file descriptor of standard output is | fd 1 rather than

Re: utilities and write errors

Date:Sun, 4 Jul 2021 19:26:25 +0100 From:Harald van Dijk Message-ID: <40fc0b0c-364f-8ff8-0613-a76c887d4...@gigawatt.nl> | I think the definition of "write", in Base Definitions, tries to say so, To a degree, yes, but I don't think that actually adds anything to

Re: utilities and write errors

On 04/07/2021 18:32, Robert Elz via austin-group-l at The Open Group wrote: Date:Thu, 1 Jul 2021 11:45:40 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20210701104540.GA4023@localhost> | it just requires pwd to write the

Re: utilities and write errors

o which is different code) already does it. I might even be convinced to change the builtin printf (which would also change /usr/bin/printf - they are the same code, more or less) to do the same thing - as those 3 utilities do nothing useful at all if the output does not appear. I doubt I would bo

Re: What string representations of "zero" expr should consider as "zero"? (was Re: utilities and write errors)

Geoff Clare via austin-group-l at The Open Group dixit: >As far as implementation detail goes, obviously if pwd uses stdio >buffering then in order to conform to the standard it must explicitly >fflush(stdout) and check there was no write error before exiting. >I see from later in the thread that

Re: utilities and write errors

2021-07-01 14:35:03 +0100, Geoff Clare via austin-group-l at The Open Group: [...] > 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: [...] So in the

Re: utilities and write errors

On 2021-06-29 17:28:40 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > But utilities are meant to behave the same whether they're > builtin or not. A non-builtin pwd writting to a closed pipe > would not cause the shell to exit. Another difference between implementations

Re: utilities and write errors

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

Re: utilities and write errors

Geoff Clare wrote in <20210701104540.GA4023@localhost>: |Robert Elz wrote, on 29 Jun 2021: ... |As above, this is all irrelevant to what the standard requires. | |As far as implementation detail goes, obviously if pwd uses stdio |buffering then in order to conform to the standard it must

Re: utilities and write errors

2021-07-01 11:45:40 +0100, Geoff Clare via austin-group-l at The Open Group: [...] > The standard says nothing about internal buffering; it just requires > pwd to write the directory to file descriptor 1. It also states that > exit status 0 means "successful completion". [...] > If an implementor

Re: utilities and write errors

Robert Elz wrote, on 29 Jun 2021: > > Date:Tue, 29 Jun 2021 09:49:40 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210629084940.GA8391@localhost> > > | You are wrong when you say it "printed it". It tried to print it but > |

Re: utilities and write errors

On 30/06/2021 16:56, Chet Ramey via austin-group-l at The Open Group wrote: On 6/30/21 11:49 AM, Joerg Schilling via austin-group-l at The Open Group wrote: Erm, yes. For some reason, I assumed the OP wrote &> instead of >& which have the same meaning in GNU bash (but &> is the parse-trouble

Re: utilities and write errors

"tg...@mirbsd.org via austin-group-l at The Open Group" wrote: > Don Cragun dixit: > > >No. > [?] > > Erm, yes. For some reason, I assumed the OP wrote &> instead of >& > which have the same meaning in GNU bash (but &> is the parse-trouble > one even if the bash manpage actively recommends

Re: utilities and write errors

On 6/30/21 11:49 AM, Joerg Schilling via austin-group-l at The Open Group wrote: Erm, yes. For some reason, I assumed the OP wrote &> instead of >& which have the same meaning in GNU bash (but &> is the parse-trouble one even if the bash manpage actively recommends it). I guess their ?~>&?

Re: utilities and write errors

On 6/29/21 5:09 PM, tg...@mirbsd.org via austin-group-l at The Open Group wrote: I know the GNU bash extension >& (which incidentally violates POSIX on the parse level) but not ~>&… It doesn't. It's been unspecified for over 30 years. -- ``The lyf so short, the craft so long to lerne.'' -

Re: utilities and write errors

On 2021-06-29 20:59:51 -0700, L A Walsh wrote: > On 2021/06/29 17:55, Vincent Lefevre wrote: > > On 2021-06-29 13:30:53 -0700, L A Walsh wrote: > > > --- > > >No. the pwd utility has had its stdout redirected by its > > > parent, "the shell". Since the faulty redirection was done by parent, >

Re: utilities and write errors

30 Haziran 2021 Çarşamba tarihinde L A Walsh via austin-group-l at The Open Group yazdı: > > Anyway, it is the parent that is directed the output to a location that > won't work as an output destination. In my example with >/dev/zero, I > got a permission denied from the parent process. If I

Re: utilities and write errors

On 2021/06/29 17:55, Vincent Lefevre wrote: On 2021-06-29 13:30:53 -0700, L A Walsh wrote: --- No. the pwd utility has had its stdout redirected by its parent, "the shell". Since the faulty redirection was done by parent, is the error in the child or the parent? The redirection is

Re: utilities and write errors

On 2021-06-30 00:46:00 +, mirabilos via austin-group-l at The Open Group wrote: > Using the same shorthand, I changed mksh tonight to do pretty much > what you described, in a second patch: > > @@ pseudo @@ > int > call_builtin(func_t builtinfunc, int argc, char *argv[]) > { > int

Re: utilities and write errors

Vincent Lefevre via austin-group-l at The Open Group dixit: > an EPIPE error; only in this case, this diagnostic message may be > annoying because the EPIPE error is an expected error (though it Yeah, this is going to be annoying. >where close_stdout check any error on stdout and stderr.

Re: utilities and write errors

Don Cragun dixit: >No. […] Erm, yes. For some reason, I assumed the OP wrote &> instead of >& which have the same meaning in GNU bash (but &> is the parse-trouble one even if the bash manpage actively recommends it). I guess their “~>&” confused me. My point of _please_ using “>file 2>&1”

Re: utilities and write errors

On 2021-06-29 13:30:53 -0700, L A Walsh wrote: > On 2021/06/27 14:33, tg...@mirbsd.org via austin-group-l at The Open Group > wrote: > > Don Cragun via austin-group-l at The Open Group dixit: > > > > > • When an unrecoverable error condition is > > > encountered, the utility shall exit with

Re: utilities and write errors

Robert Elz via austin-group-l at The Open Group dixit: > | > 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. >There was no argument based upon C functions - the use of them was >just a

Re: utilities and write errors

On 2021-06-29 17:28:40 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > 2021-06-29 16:28:17 +0200, Vincent Lefevre via austin-group-l at The Open > Group: > [...] > > > ( > > > sleep 1 > > > set +o errexit -o xtrace > > > pwd > > > pwd > > > ) | : > > > > > > Calls

Re: utilities and write errors

On 2021-06-29 22:43:49 +0700, Robert Elz via austin-group-l at The Open Group wrote: > Date:Tue, 29 Jun 2021 09:49:40 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210629084940.GA8391@localhost> > > | You are wrong when you

Re: utilities and write errors

> On Jun 29, 2021, at 3:20 PM, tg...@mirbsd.org via austin-group-l at The Open > Group wrote: > >> ... ... ... > > Ah, so you meant… > >> "/tmp cd ~ >& /dev/zero" > > … which was not clear from the punctuation salad you posted. > >> "Violates POSIX on the parse level?!" Eek! Next > > It

Re: utilities and write errors

On 2021/06/29 15:20, tg...@mirbsd.org wrote: "/tmp cd ~ >& /dev/zero" cd ~>& is parsed correctly in more "intelligent" parsers. "Violates POSIX on the parse level?!" Eek! Next It does: >& is parsed as > & by POSIX rules, TTBOMK. --- "What? WHAT?" Your abbreviation is

Re: utilities and write errors

L A Walsh dixit: >> What? WHAT? >> >> Could you please translate that to proper sh syntax? >> I know the GNU bash extension >& (which incidentally >> violates POSIX on the parse level) but not ~>&… >> > POSIX doesn't allow 'cd ~' to change to your home Ah, so you meant… > "/tmp cd ~ >&

Re: utilities and write errors

On 2021/06/29 14:09, tg...@mirbsd.org wrote: L A Walsh via austin-group-l at The Open Group dixit: along those lines: /tmp pwd >& /dev/zero -bash: /dev/zero: Permission denied /tmp> echo $? 1 /tmp> cd ~>& /dev/zero #note the command isn't executed -bash: /dev/zero:

Re: utilities and write errors

L A Walsh via austin-group-l at The Open Group dixit: > along those lines: > > /tmp pwd >& /dev/zero > -bash: /dev/zero: Permission denied > /tmp> echo $? > 1 > /tmp> cd ~>& /dev/zero #note the command isn't executed > -bash: /dev/zero: Permission denied > /tmp> What? WHAT?

Re: utilities and write errors

On 2021/06/29 13:30, L A Walsh via austin-group-l at The Open Group wrote: On 2021/06/27 14:33, tg...@mirbsd.org via austin-group-l at The Open Group wrote: Is “pwd >/dev/full” an “unrecoverable error condition” as regards the pwd utility? --- No. the pwd utility has had its stdout

Re: utilities and write errors

On 2021/06/27 14:33, tg...@mirbsd.org via austin-group-l at The Open Group wrote: Don Cragun via austin-group-l at The Open Group dixit: • When an unrecoverable error condition is encountered, the utility shall exit with a non-zero exit status. Is “pwd

Re: utilities and write errors

ncerned here) can be anything. But of course, those programs are likely to be specified somewhere (even if just in their own man page) and should do what they're documented to do. The issue here is just that (for the purpose of deciding what POSIX requires) doing tests using >&- to force wr

Re: utilities and write errors

2021-06-29 16:28:17 +0200, Vincent Lefevre via austin-group-l at The Open Group: [...] > > ( > > sleep 1 > > set +o errexit -o xtrace > > pwd > > pwd > > ) | : > > > > Calls pwd only once with most shell implementations (all those > > where pwd is builtin). > > > > Is that allowed? > >

Re: utilities and write errors

Date:Tue, 29 Jun 2021 09:49:40 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20210629084940.GA8391@localhost> | You are wrong when you say it "printed it". It tried to print it but | failed to do so. But how do you actually know?

Re: utilities and write errors

On 2021-06-29 14:11:45 +0100, Stephane Chazelas via austin-group-l at The Open Group wrote: > 2021-06-29 09:49:40 +0100, Geoff Clare via austin-group-l at The Open Group: > [...] > > > If in general, then forget it - the users would lynch you (you'd probably > > > suicide first) if you

Re: utilities and write errors

2021-06-29 09:49:40 +0100, Geoff Clare via austin-group-l at The Open Group: [...] > > If in general, then forget it - the users would lynch you (you'd probably > > suicide first) if you successfully caused that to happen. > > No they wouldn't. The only reason to set SIGPIPE to be ignored is >

Re: utilities and write errors

statement of… > > >On Solaris 11 (certified as compliant): > > … which makes me think that (besides significant vocal support on > this list) there’s significant precedent for this real-existing, > historically-founded, behaviour of not having to check for all > kinds of stdou

Re: utilities and write errors

Robert Elz wrote, on 28 Jun 2021: > > 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

Re: utilities and write errors

On Mon, Jun 28, 2021 at 2:53 PM Vincent Lefevre via austin-group-l at The Open Group wrote: > On 2021-06-28 21:28:37 +0700, Robert Elz wrote: > > Date:Mon, 28 Jun 2021 15:48:33 +0200 > > From:Vincent Lefevre > > Message-ID: <20210628134833.ga46...@zira.vinc17.org> >

Re: utilities and write errors

I forgot another useful case with write error checking. For instance, I expect the following command to terminate, which is not the case with ksh: ( trap '' PIPE; while pwd; do :; done; ) | head Worse, with ksh93, when I hit Ctrl-C to interrupt this command, a ksh93 process is still running,

Re: utilities and write errors

eep 1; /bin/sh -c 'pwd; echo "$?" >&2') | : > >0 > > That goes with your statement of… > > >On Solaris 11 (certified as compliant): > > … which makes me think that (besides significant vocal support on > this list) there’s significant precedent for

Re: utilities and write errors

On 2021-06-28 21:28:37 +0700, Robert Elz wrote: > Date:Mon, 28 Jun 2021 15:48:33 +0200 > From:Vincent Lefevre > Message-ID: <20210628134833.ga46...@zira.vinc17.org> > > | So, if writing to a closed fd yields unspecified behaviour, what > | does "refers to no open

Re: utilities and write errors

rt on this list) there’s significant precedent for this real-existing, historically-founded, behaviour of not having to check for all kinds of stdout/stderr write errors for utilities “like that” (I’d expect text editors, for example, to still show errors of course), the boundary of “like t

Re: utilities and write errors

Date:Mon, 28 Jun 2021 15:48:33 +0200 From:Vincent Lefevre Message-ID: <20210628134833.ga46...@zira.vinc17.org> | So, if writing to a closed fd yields unspecified behaviour, what | does "refers to no open file" mean? No, you misunderstood. It isn't writing to

Re: utilities and write errors

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

Re: utilities and write errors

2021-06-28 20:01:03 +0700, Robert Elz: [...] > steph...@chazelas.org said: > | On the zsh mailing list, where the issue was initially brought up by > | Vincent, there was also the mention that EBADF error was explicitly > | ignore as a special case, as some systems have or used to have > |

Re: utilities and write errors

Date:Mon, 28 Jun 2021 13:26:48 +0200 From:"Joerg Schilling via austin-group-l at The Open Group" Message-ID: <20210628112648.qkgag%sch...@schily.net> Several messages to which to reply ... but I'll start with the easy ones. | It could be argued that setting up

Re: utilities and write errors

"Robert Elz via austin-group-l at The Open Group" wrote: > Date:Mon, 28 Jun 2021 10:03:39 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210628090339.GA13976@localhost> > > | The (builtin) pwd utility got an error when it

Re: utilities and write errors

2021-06-28 12:06:34 +0100, Geoff Clare via austin-group-l at The Open Group: [...] > > It has been tradition, for a very long time, for writes on stdout to > > have errors ignored - particularly in a case like this, where because > > of the redirection, stdout is probably buffered, and not a lot

Re: utilities and write errors

Robert Elz wrote, on 28 Jun 2021: > > Date:Mon, 28 Jun 2021 10:03:39 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210628090339.GA13976@localhost> > > | The (builtin) pwd utility got an error when it tried to write() to > |

Re: utilities and write errors

2021-06-28 17:28:04 +0700, Robert Elz via austin-group-l at The Open Group: [...] > A more blatant case would be > > pwd | (exit 0) [...] On the zsh mailing list, where the issue was initially brought up by Vincent, there was also the mention that EBADF error was explicitly ignore as a

Re: utilities and write errors

Date:Mon, 28 Jun 2021 10:03:39 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20210628090339.GA13976@localhost> | The (builtin) pwd utility got an error when it tried to write() to | standard output. But did it "encounter" the error?

Re: utilities and write errors

tg...@mirbsd.org wrote, on 27 Jun 2021: > > Don Cragun via austin-group-l at The Open Group dixit: > > > • When an unrecoverable error condition is > > encountered, the utility shall exit with a > > non-zero exit status. > > Is “pwd >/dev/full” an “unrecoverable error condition”

Re: utilities and write errors

> On Jun 27, 2021, at 2:33 PM, tg...@mirbsd.org wrote: > > Don Cragun via austin-group-l at The Open Group dixit: > >> • When an unrecoverable error condition is >>encountered, the utility shall exit with a >>non-zero exit status. Please do not cherry pick what you quote

Re: utilities and write errors

Don Cragun via austin-group-l at The Open Group dixit: > • When an unrecoverable error condition is > encountered, the utility shall exit with a > non-zero exit status. Is “pwd >/dev/full” an “unrecoverable error condition” as regards the pwd utility? I think not. It

Re: utilities and write errors

Section 1.4 of the Commands and Utilities Volume of the standard (Utility Description Defaults) already does this in the CONSEQUENCES OF ERRORS section on P2303-2304, L74122-74151 in P1003.1-202x Draft 2 and on P2341-2342, L74540-74569 in P1003.1-2017. Note especially: The following shall

utilities and write errors

Shouldn't POSIX require that when a utility cannot write its output (e.g. due to ENOSPC or EPIPE), it shall be regarded as an error, i.e. the exit status be non zero, with a diagnostic message if possible? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML -