On Tue, Dec 10, 2024 at 05:10:08PM -0500, Chet Ramey wrote:
> On 12/10/24 4:41 AM, Mike Jonkmans wrote:
>
> > Also compare:
> > $ if false; then echo foo; fi
> > $ echo "ret = $?, status = ${PIPESTATUS[*]}"
> > ret = 0, status = 1
> > To:
> > $ if ! :; then echo foo; fi
> > $ echo "ret = $?, status = ${PIPESTATUS[*]}"
> > ret = 0, status = 0
> >
> > The '! :' is a pipeline with status = 1.
> > Yet it is not reflected in PIPESTATUS.
>
> OK, extend that. The `!' applies to the pipeline, not necessarily to all
> the commands in it, since the status of a pipeline is the status of the
> last element (ignore pipefail for now).
I am under the impression that '!' is part of the pipeline.
But re-reading the documentation, see below, explains the behaviour.
> So, given
> ! true | false
Or worse: '! true | ! true' is a syntax error!?
Also errors in dash, but not in ksh.
Can a command - as part of a pipeline - not be a pipeline?
> how should the negation be reflected in the values assigned to PIPESTATUS?
> Since one use of PIPESTATUS is to find out which pipeline element(s)
> succeeded and which failed, how is modifying some element of PIPESTATUS
> here helpful?
The actual behaviour of $? and PIPESTATUS are fine (with me).
What bothers me (only slightly), is the documentation.
Specifically the text on PIPESTATUS:
An array variable (see Arrays below) containing a list of exit
status values from the processes in the most-recently-executed
foreground pipeline (which may contain only a single command).
The 'most-recently-executed' might need some explanation.
Or do you think that it should be clear?
Maybe the manpage is not the right place.
The text 'exit statuses from the *processes* in the ...pipeline',
is (too?) subtle in its use of the word 'processes'.
Processes in a pipeline, can be seen as ruling out the '!' (and 'time')
part of the pipeline.
Maybe rephrase: ... processes (within commands)...
Or maybe not, as it doesn't explain:
if ! case a in esac; then :; fi
Writing (and reading) documentation is not so easy.
--
Regards, Mike Jonkmans
