Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apparent improper handling of SIGPIPE #6351

Open
p6rt opened this issue Jun 20, 2017 · 3 comments
Open

Apparent improper handling of SIGPIPE #6351

p6rt opened this issue Jun 20, 2017 · 3 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Jun 20, 2017

Migrated from rt.perl.org#131608 (status was 'open')

Searchable as RT131608$

@p6rt
Copy link
Author

p6rt commented Jun 20, 2017

From frettled@gmail.com

According to a brief mail discussion on perl6-users
(https://www.nntp.perl.org/group/perl.perl6.users/2017/06/msg3905.html
and subsequent messages), Rakudo seems to improperly handle piping
with e.g. head, and therefore most likely any other kind of external
program that would close a pipe.

For the sake of bug record keeping, here's the relevant snippet of the
discussion.

On Fri, Jun 16, 2017 at 12​:13 PM, Elizabeth Mattijsen wrote​:

Failed to write bytes to filehandle​: Broken pipe
in block <unit> at -e line 1

So it would appear this got fixed by the synchronous IO refactor, and will be available in the 2017.06 release, which is scheduled for tomorrow.

This appears to be only a partial fix with an unexpected outcome.

awk, Perl 5, Ruby, etc. do not generate errors for similar use of
pipes, and instead use exit status 0.

PS​: I have not installed the latest Rakudo myself, this just caught my
interest, and I was asked to file a rakudobug about it.

--
Jan

@p6rt
Copy link
Author

p6rt commented Jun 26, 2017

From @Leont

On Tue, 20 Jun 2017 06​:12​:54 -0700, jani wrote​:

According to a brief mail discussion on perl6-users
(https://www.nntp.perl.org/group/perl.perl6.users/2017/06/msg3905.html
and subsequent messages), Rakudo seems to improperly handle piping
with e.g. head, and therefore most likely any other kind of external
program that would close a pipe.

For the sake of bug record keeping, here's the relevant snippet of the
discussion.

The problem with the unix default SIGPIPE handling is that while it's very useful for command-line applications, it's most annoying for pretty much anything else (in particular networking applications).

Regardless of the default, this needs an easy to use switch to toggle the behavior.

Leon

@p6rt
Copy link
Author

p6rt commented Jun 26, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant