broken pipe message with setopt PRINT_EXIT_VALUE

broken pipe message with setopt PRINT_EXIT_VALUE

[Samuel Bancal]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

Dear zsh workers,

I'm using zsh on Ubuntu 20.04 (and oh-my-zsh).

When running the following command, I get the following error.

< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32; echo;
XKCxcd1QQ8otBre05qUDrvw2GFIdpYNr[1]    97774 broken pipe  tr -dc 
_A-Z-a-z-0-9 < /dev/urandom |
        97775 done         head -c 32

The expected output is :

< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32; echo;
XKCxcd1QQ8otBre05qUDrvw2GFIdpYNr

After investigations ( https://stackoverflow.com/q/67738240/446302 ) it 
seems to be related to the fact that I have set the option setopt 
PRINT_EXIT_VALUE in my ~/.zshrc

Steps to reproduce :

  * install Ubuntu 20.04
  * sudo apt install zsh
  * zsh # populate your ~/.zshrc with recommended configuration
  * < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32; echo;
    # that works as expected -> give a random 32 chars
  * setopt PRINT_EXIT_VALUE
  * < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32; echo;
    # expected output + a broken pipe error message

What do you think of it ?

Regards,
Samuel Bancal


-- 
*Samuel Bancal*
/IT Eng /
*ENAC-IT *
/GR A0 464/
EPFL

ENAC-IT is opening a new branch IT4Research 
<https://www.epfl.ch/schools/enac/about/data-services-en/> /to better 
support our labs in leveraging data in their research! Contact us with 
any questions related to data management, / /data valorization, data 
science and computational tools.
/


[-- Attachment #2.1: Type: text/html, Size: 4587 bytes --]

[-- Attachment #2.2: nkpjlfilkffncmgb.png --]
[-- Type: image/png, Size: 984 bytes --]

Re: broken pipe message with setopt PRINT_EXIT_VALUE

[Stephane Chazelas]

2021-05-28 19:06:00 +0200, Samuel Bancal:
[...]
> < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32; echo;
> XKCxcd1QQ8otBre05qUDrvw2GFIdpYNr[1]    97774 broken pipe  tr -dc
> _A-Z-a-z-0-9 < /dev/urandom |
>        97775 done         head -c 32
[...]

Same in yes | head -n 1

In both cases, tr/yes are being killed (with a SIGPIPE) because
they're trying to write to a pipe that has no reader. If they
weren't killed they would run forever as /dev/urandom is of
infinite size and yes never terminates.

When a process is killed, it returns a non-zero (failure) exit
status to its parent.

Which is printed (or rather here the "broken pipe" message
corresponding to that death-by-SIGPIPE) because of
PRINT_EXIT_VALUE.

PRINT_EXIT_VALUE (-1)
     Print the exit value of programs with non-zero exit status.  This
     is only available at the command line in interactive shells.

Even if you ignored SIGPIPE (which in general you don't want to):

~$ (trap '' PIPE; yes) | head -n1
y
yes: standard output: Broken pipe
zsh: exit 1     ( trap '' PIPE; yes; ) |
zsh: done       head -n1

You still get a message as this time, yes exit with a failure
status because the write it tried to do on that pipe failed with
a "EPIPE" error.

-- 
Stephane

Re: broken pipe message with setopt PRINT_EXIT_VALUE

[Bart Schaefer]

On Fri, May 28, 2021 at 1:02 PM Stephane Chazelas <stephane@chazelas.org> wrote:
>
> In both cases, tr/yes are being killed (with a SIGPIPE) because
> they're trying to write to a pipe that has no reader. [...]
>
> Which is printed (or rather here the "broken pipe" message
> corresponding to that death-by-SIGPIPE) because of
> PRINT_EXIT_VALUE.

Which is exactly what's supposed to happen when you have that set.

You can run the pipeline in a subshell to suppress this behavior:

( < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32; echo )

PRINT_EXIT_VALUE is disabled in subshells because subshells do not
normally maintain a jobs table like an interactive shell does.

Re: broken pipe message with setopt PRINT_EXIT_VALUE

[Samuel Bancal]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

Thanks for these insights.

Yes, I think that behavior makes sense.
I find the solution to run in a subshell really clean and elegant.

Regards,
Samuel

On 28.05.21 23:26, Bart Schaefer wrote:
> On Fri, May 28, 2021 at 1:02 PM Stephane Chazelas <stephane@chazelas.org> wrote:
>> In both cases, tr/yes are being killed (with a SIGPIPE) because
>> they're trying to write to a pipe that has no reader. [...]
>>
>> Which is printed (or rather here the "broken pipe" message
>> corresponding to that death-by-SIGPIPE) because of
>> PRINT_EXIT_VALUE.
> Which is exactly what's supposed to happen when you have that set.
>
> You can run the pipeline in a subshell to suppress this behavior:
>
> ( < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32; echo )
>
> PRINT_EXIT_VALUE is disabled in subshells because subshells do not
> normally maintain a jobs table like an interactive shell does.
-- 
*Samuel Bancal*
/IT Eng /
*ENAC-IT *
/GR A0 464/
EPFL

ENAC-IT is opening a new branch IT4Research 
<https://www.epfl.ch/schools/enac/about/data-services-en/> /to better 
support our labs in leveraging data in their research! Contact us with 
any questions related to data management, / /data valorization, data 
science and computational tools.
/


[-- Attachment #2.1: Type: text/html, Size: 4504 bytes --]

[-- Attachment #2.2: acacdmolhgnidcmc.png --]
[-- Type: image/png, Size: 984 bytes --]

Re: broken pipe message with setopt PRINT_EXIT_VALUE

[Daniel Shahaf]

Bart Schaefer wrote on Fri, May 28, 2021 at 14:26:25 -0700:
> You can run the pipeline in a subshell to suppress this behavior:
> 
> ( < /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32; echo )
> 
> PRINT_EXIT_VALUE is disabled in subshells because subshells do not
> normally maintain a jobs table like an interactive shell does.

That's the reason in implementation terms, but what's the reason in
user-facing terms?

Re: broken pipe message with setopt PRINT_EXIT_VALUE

[Bart Schaefer]

On Sat, May 29, 2021 at 4:44 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Bart Schaefer wrote on Fri, May 28, 2021 at 14:26:25 -0700:
> > PRINT_EXIT_VALUE is disabled in subshells because subshells do not
> > normally maintain a jobs table like an interactive shell does.
>
> That's the reason in implementation terms, but what's the reason in
> user-facing terms?

Command grouping.  The exit value of the subshell is still printed by
the parent if the whole group's status is nonzero.

Re: broken pipe message with setopt PRINT_EXIT_VALUE

[Daniel Shahaf]

Bart Schaefer wrote on Sat, 29 May 2021 15:52 +00:00:
> On Sat, May 29, 2021 at 4:44 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > Bart Schaefer wrote on Fri, May 28, 2021 at 14:26:25 -0700:
> > > PRINT_EXIT_VALUE is disabled in subshells because subshells do not
> > > normally maintain a jobs table like an interactive shell does.
> >
> > That's the reason in implementation terms, but what's the reason in
> > user-facing terms?
> 
> Command grouping.  The exit value of the subshell is still printed by
> the parent if the whole group's status is nonzero.

This implies that it's a bug that «{ false;  true }» prints a PRINT_EXIT_VALUE
message for «false».

Cheers,

Daniel

Re: broken pipe message with setopt PRINT_EXIT_VALUE

[Bart Schaefer]

On Sun, May 30, 2021 at 5:31 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> This implies that it's a bug that «{ false;  true }» prints a PRINT_EXIT_VALUE
> message for «false».

I'm not interested enough in the answer to say any more about it.  If
you want to dig up the original implementation discussion, go for it.