Re: Not to set PIPESTATUS unless necessary

[Koichi Murase]

2024年5月9日(木) 10:57 Peng Yu <pengyu.ut@gmail.com>:
> available in $?. Therefore, I think it is unnecessary to set
> PIPESTATUS after false. It is better to preserve its value until it is
> really necessary.

That breaks the backward compatibility. Existing scripts can be broken.

> Is there already a switch to turn on the behavior that I suggested?

I don't think so.

> If not, can this feature be added?

Adding a switch might work around the compatibility issue from the
user's perspective.

However, for the libraries or frameworks that need to offer support
under an arbitrary set of switches that users control, an additional
switch requires additional workarounds. I'm not even sure if that
switch can be worked around in a general case. For example, when a
framework wants to run a user-supplied command stored in a variable
`var' (where whether `var' contains a pipe connection is unknown
before running the command) in a user-supplied set of shell options
and record the results of the command, the framework might do « eval
"$var; lastexit=$? saved=(\"\${PIPESTATUS[@]}\")" ». This can be
broken even when the new behavior is controlled by a new switch. One
new switch means that the number of test cases for a library naively
doubles.

Also, there seems to be a case where PIPESTATUS and $? are different [1,2].

[1] https://lists.gnu.org/archive/html/help-bash/2013-12/threads.html#00008
[2] https://lists.gnu.org/archive/html/bug-bash/2024-04/threads.html#00132

> Otherwise, users will have to preserve PIPESTATUS
> after running true | true. This will result in more code to write.

The users need to preserve PIPESTATUS, but the users can still do that
to achieve the purpose. Is it worth adding a switch while increasing
the compatibility issues? Is there a case that is impossible to
achieve without the suggested switch?

--
Koichi