GNU bug report logs - #34488
Add sort --limit, or document workarounds for sort|head error messages

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34488 in the body.
You can then email your comments to 34488 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-coreutils <at> gnu.org
Subject: Add sort --limit, or document workarounds for sort|head error messages
Date: Fri, 15 Feb 2019 22:43:48 +0800

Things start out cheery, but quickly get ugly,

$ for i in 9 99 999 9999 99999; do seq $i|sort -n|sed 5q|wc -l; done
5
5
5
5
sort: write failed: 'standard output': Broken pipe
sort: write error
5
sort: write failed: 'standard output': Broken pipe
sort: write error

Therefore, kindly add a sort --limit=n,
and/or on (info "(coreutils) sort invocation")
admit the problem, and give some workarounds, lest
our scripts occasionally spew error messages seemingly randomly,
just when the boss is looking.

And no fair saying "just save the output" (could be big) "into a file
first, and do head(1) or sed(1) on that."

Message #8 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Fri, 15 Feb 2019 09:20:58 -0600

[Message part 1 (text/plain, inline)]

On 2/15/19 8:43 AM, 積丹尼 Dan Jacobson wrote:
> Things start out cheery, but quickly get ugly,
> 
> $ for i in 9 99 999 9999 99999; do seq $i|sort -n|sed 5q|wc -l; done
> 5
> 5
> 5
> 5
> sort: write failed: 'standard output': Broken pipe
> sort: write error
> 5
> sort: write failed: 'standard output': Broken pipe
> sort: write error

Your code is demonstrating what happens when sed ends processing without
consuming all of sort's output, to the point that sort is producing more
output than what stdio can buffer, and thus with enough pending output
will trigger a situation of SIGPIPE - but when SIGPIPE is ignored, that
instead turns into an EPIPE failure to write(), and sort treats all
write() failures as worthy of error reporting.  If you want sort to die
silently, then don't ignore SIGPIPE, so that sort won't see EPIPE and
thus won't be noisy.

$ (trap '' PIPE; seq 9999 | sort -n | sed 5q | wc -l)
5
sort: write failed: 'standard output': Broken pipe
sort: write error
$ (trap - PIPE; seq 9999 | sort -n | sed 5q | wc -l)
5

Except that POSIX has the nasty requirement that sh started with an
inherited ignored SIGPIPE must silently ignore all attempts from within
the shell to restore SIGPIPE handling to child processes of the shell:

$ (trap '' PIPE; bash -c 'trap - PIPE; \
   seq 9999 | sort -n | sed 5q | wc -l')
5
sort: write failed: 'standard output': Broken pipe
sort: write error

And unfortunately, there are several common cases of badly-behaved
environment setups that leave SIGPIPE ignored in the child (for example,
a quick google search found this:
https://blog.nelhage.com/2010/02/a-very-subtle-bug/)

You HAVE to use some other intermediate program if you want to override
an inherited ignored SIGPIPE in sh into an inherited default-behavior
SIGPIPE in sort.

Perhaps coreutils should teach 'env' a command-line option to forcefully
reset SIGPIPE back to default behavior (or add a new coreutil that does
the same idea), as a way to work around POSIX' requirement on sh.  If we
did that, then even if your sh is started with SIGPIPE ignored (so that
the shell itself can't restore default behavior), you could do this
theoretical invocation:

$ seq 9999 | env --default-signal PIPE sort -n | sed 5q | wc -l
5

and avoid the EPIPE failures because sort is forced to start with
SIGPIPE handling rather than ignored.

> 
> Therefore, kindly add a sort --limit=n,

Not scalable.  The problem you encountered is NOT the fault of sort, but
is common to ALL utilities which dutifully report write() failures on
EPIPE errors, which in turn happens when SIGPIPE is ignored.  Adding an
option to every such utility that produces outtput is not a good use of
time.  If you want to change things universally, perhaps you should
petition POSIX to change the requirements to allow applications the
option to silently exit without an error message on EPIPE failures to
write(), instead of the current wording that all write() errors must be
diagnosed.

> and/or on (info "(coreutils) sort invocation")
> admit the problem, and give some workarounds, lest
> our scripts occasionally spew error messages seemingly randomly,
> just when the boss is looking.

The problem is not in sort, but in the fact that your environment is
ignoring SIGPIPE. Documenting something in sort doesn't scale, but
perhaps the documentation could mention SIGPIPE considerations in a more
global chapter covering all of the coreutils.

> 
> And no fair saying "just save the output" (could be big) "into a file
> first, and do head(1) or sed(1) on that."
> 

If you have an app that exits noisily on write failures to an early-exit
pipe, your solutions are to quit ignoring SIGPIPE, or to change the
pipeline to consume all of the output instead of exiting early and
causing write failure.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Fri, 15 Feb 2019 08:37:48 -0700

severity 34488 wishlist
retitle 34488 doc: sort: expand on "broken pipe" (SIGPIPE) behavior
stop

Hello,

On 2019-02-15 7:43 a.m., 積丹尼 Dan Jacobson wrote:
> Things start out cheery, but quickly get ugly,
> 
> $ for i in 9 99 999 9999 99999; do seq $i|sort -n|sed 5q|wc -l; done
> 5
> 5
> 5
> 5
> sort: write failed: 'standard output': Broken pipe
> sort: write error
> 5
> sort: write failed: 'standard output': Broken pipe
> sort: write error
> 
> Therefore, kindly add a sort --limit=n,

I don't think this is wise, as "head -n5" does exactly that in much more
generic way.

> and/or on (info "(coreutils) sort invocation")
> admit the problem, and give some workarounds, lest
> our scripts occasionally spew error messages seemingly randomly,
> just when the boss is looking.

Just to clarify: why do you think this a "problem" ?

This is the intended behavior of most proper programs:
Upon receiving SIGPIPE they should terminal with an error,
unless SIGPIPE is explicitly ignored.
The errors are not "random" - they happen because you explicitly
cut short the output of a program.

It is an important indication about how your pipe works,
and sort is not to blame, e.g.:

    $ seq 100000 | head -n1
    1
    seq: write error: Broken pipe

    $ seq 1000000| cat | head -n1
    1
    cat: write error: Broken pipe
    seq: write error: Broken pipe

This is a good indication that the entire output was not consumed,
and is very useful and important in some cases, e.g. when a program
crashes before consuming all input.

Here's a contrived example:

   $ seq 1000000 | sort -S 200 -T /foo/bar
   sort: cannot create temporary file in '/foo/bar': No such file or 
directory
   seq: write error: Broken pipe

I force "sort" to fail (limiting it's memory usage and pointing it to
non-existing temporarily directory).
It is then good to know that seq's output was cut short and not consumed.

If you know in advance you will trim the output of a program,
either hide the stderr with "2>/dev/null",
or use the shell's "trap PIPE" mechanism.

> And no fair saying "just save the output" (could be big) "into a file
> first, and do head(1) or sed(1) on that."

If you want to consume all input and just print the first 5 lines,
you can use "sed -n 1,5p" instead of "sed 5q" - no need for a temporary
file.


I'm marking this as a documentation "wishlist" item,
and patches are always welcomed.

regards,
 - assaf

Message #14 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit,
 or document workarounds for sort|head error messages
Date: Fri, 15 Feb 2019 23:49:38 +0800

>>>>> "AG" == Assaf Gordon <assafgordon <at> gmail.com> writes:
AG> The errors are not "random" - they happen because you explicitly
AG> cut short the output of a program.

Well the user thinks "hey I cut short 5 lines, 45 lines, 495 lines, and
then one I got a job at a big company and cut short 4995 lines and got
this error message just when the boss was looking."

So be sure to mention it. Thanks.

Message #17 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit,
 or document workarounds for sort|head error messages
Date: Sat, 16 Feb 2019 00:53:07 +0800

>>>>> "EB" == Eric Blake <eblake <at> redhat.com> writes:

>> And no fair saying "just save the output" (could be big) "into a file
>> first, and do head(1) or sed(1) on that."

EB> If you have an app that exits noisily on write failures to an early-exit
EB> pipe, your solutions are to quit ignoring SIGPIPE, or to change the
EB> pipeline to consume all of the output instead of exiting early and
EB> causing write failure.

OK, it seems that indeed it would then be best to document:

     If you want to make sure no such errors occur on large output,
     instead of
     $ sort | head
     use
     $ sort > file; head file

as an _easy to remember_ alternative amongst the many.

And OK put this in some general place, and have the sort, etc. pages
link to it. Thanks.

Message #20 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Eric Blake <eblake <at> redhat.com>, 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>, 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Fri, 15 Feb 2019 14:40:07 -0700

[Message part 1 (text/plain, inline)]

Helo,

On 2019-02-15 8:20 a.m., Eric Blake wrote:
> On 2/15/19 8:43 AM, 積丹尼 Dan Jacobson wrote:
>> sort: write failed: 'standard output': Broken pipe
>> sort: write error
[...]
> Perhaps coreutils should teach 'env' a command-line option to forcefully
> reset SIGPIPE back to default behavior [...]   If we
> did that, then even if your sh is started with SIGPIPE ignored (so that
> the shell itself can't restore default behavior), you could do this
> theoretical invocation:
> 
> $ seq 9999 | env --default-signal PIPE sort -n | sed 5q | wc -l
> 5

That is a nice idea, I could've used it myself couple of times.

Attached a suggested patch.
If this seems like a good direction, I'll complete it with NEWS/docs/etc.

Usage is:
    env --default-signal=PIPE
    env -P     ##shortcut to reset SIGPIPE
    env --default-signal=PIPE,INT,FOO


This also works nicely with the recent 'env -S' option,
so a script like so can always start with default SIGPIPE handler:

    #!/usr/bin/env -S -P sh
    seq inf | head -n1



comments welcomed,
 - assaf

[0001-env-new-option-D-default-signal-SIG-FIXME.patch (text/x-patch, attachment)]

Message #23 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Assaf Gordon <assafgordon <at> gmail.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Fri, 15 Feb 2019 16:11:10 -0600

[Message part 1 (text/plain, inline)]

On 2/15/19 3:40 PM, Assaf Gordon wrote:
> Helo,
> 
> On 2019-02-15 8:20 a.m., Eric Blake wrote:
>> On 2/15/19 8:43 AM, 積丹尼 Dan Jacobson wrote:
>>> sort: write failed: 'standard output': Broken pipe
>>> sort: write error
> [...]
>> Perhaps coreutils should teach 'env' a command-line option to forcefully
>> reset SIGPIPE back to default behavior [...]   If we
>> did that, then even if your sh is started with SIGPIPE ignored (so that
>> the shell itself can't restore default behavior), you could do this
>> theoretical invocation:
>>
>> $ seq 9999 | env --default-signal PIPE sort -n | sed 5q | wc -l
>> 5
> 
> That is a nice idea, I could've used it myself couple of times.
> 
> Attached a suggested patch.
> If this seems like a good direction, I'll complete it with NEWS/docs/etc.

Would we also want an easy way to ignore signals? That's a bit less of
an issue, since you can use 'trap "" $SIG' in the shell; but having the
symmetry in env may be nice (especially since using 'trap' is asymmetric
in that you can't force the shell to un-ignore an inherited ignored signal).

> 
> Usage is:
>     env --default-signal=PIPE
>     env -P     ##shortcut to reset SIGPIPE

Nice, since that's probably the most common use case for it.

>     env --default-signal=PIPE,INT,FOO
> 
> 
> This also works nicely with the recent 'env -S' option,
> so a script like so can always start with default SIGPIPE handler:
> 
>     #!/usr/bin/env -S -P sh
>     seq inf | head -n1

Also nice.


>  
> -static char const shortopts[] = "+C:iS:u:v0 \t";
> +/* if true, at least one signal handler should be reset.  */
> +static bool reset_signals ;

Extra space.

> +
> +/* if element [SIGNUM] is true, the signal handler's should be reset
> +   to its defaut. */

default

> +static bool signal_handlers[SIGNUM_BOUND];
> +
> +
> +static char const shortopts[] = "+C:iPS:u:v0 \t";

In the patch subject, you mentioned -D as a synonym to --default-signal,
but it's missing here.  (-P as a synonym to --default-signal=PIPE is
fine, though)

>  
>  static struct option const longopts[] =
>  {
> @@ -56,6 +68,7 @@ static struct option const longopts[] =
>    {"null", no_argument, NULL, '0'},
>    {"unset", required_argument, NULL, 'u'},
>    {"chdir", required_argument, NULL, 'C'},
> +  {"default-signal", optional_argument, NULL, 'P'},

Wait, you're making -P a synonym to --default-signal, even though -P
takes no options but --default-signal does? And the fact that it is
optional_argument means that you can't have a short option -D (that is,
'--default-signal FOO' is NOT the same as '--default-signal=FOO', but
treats FOO as a program name rather than a signal list).  optional
arguments can be odd; I'd consider using required_argument.

> +static void
> +parse_signal_params (const char* optarg)
> +{
> +  char signame[SIG2STR_MAX];
> +  char *opt_sig;
> +  char *optarg_writable = xstrdup (optarg);
> +
> +  opt_sig = strtok (optarg_writable, ",");
> +  while (opt_sig)
> +    {
> +      int signum = operand2sig (opt_sig, signame);
> +      if (signum < 0)
> +        usage (EXIT_FAILURE);

Is blind usage() the best, or should we quote the unrecognized signal
name via error() to call attention to which part of the command line failed?

> +
> +      signal_handlers[signum] = true;
> +
> +      opt_sig = strtok (NULL, ",");
> +    }
> +
> +  free (optarg_writable);
> +}
> +
> +static void
> +reset_signal_handlers (void)
> +{
> +
> +  if (!reset_signals)
> +    return;
> +
> +  if (dev_debug)
> +      devmsg ("Resetting signal handlers:\n");
> +
> +  for (int i=0; i<SIGNUM_BOUND; ++i)

Spaces around =

> +    {
> +      struct sigaction act;
> +
> +      if (!signal_handlers[i])
> +        continue;
> +
> +      if (dev_debug)
> +        {
> +          char signame[SIG2STR_MAX];
> +          sig2str (i, signame);
> +          devmsg ("   %s (%d)\n", signame, i);
> +        }
> +
> +        if (sigaction (i, NULL, &act))
> +          die (EXIT_CANCELED, errno, _("sigaction1(sig=%d) failed"), i);
> +
> +        act.sa_handler = SIG_DFL;
> +        if (sigaction (i, &act, NULL))
> +          die (EXIT_CANCELED, errno, _("sigaction2(sig=%d) failed"), i);

Why do you have to call sigaction() twice? Is it to make sure the rest
of &act is set up correctly?  But what else in &act needs setup if you
are going to set things to SIG_DFL?

> +
> +
> +    }
> +}

Why 2 blank lines?

> +
>  int
>  main (int argc, char **argv)
>  {
> @@ -558,6 +637,13 @@ main (int argc, char **argv)
>          case '0':
>            opt_nul_terminate_output = true;
>            break;
> +        case 'P':
> +          reset_signals = true;
> +          if (optarg)
> +            parse_signal_params (optarg);
> +          else
> +            signal_handlers[SIGPIPE] = true;
> +          break;

Hmm - you made it optional so that '--default-signal' and
'--default-signal=PIPE' can be synonyms.  If so, the help text in
usage() should definitely call out "--default-signal[=LIST]" to make it
obvious that LIST is an optional argument.


> +++ b/tests/misc/env-signal-handler.sh

> +. "${srcdir=.}/tests/init.sh"; path_prepend_ ./src
> +print_ver_ seq
> +trap_sigpipe_or_skip_

Hmm - I wonder if trap_sigpipe_or_skip_ could be updated to take
advantage of our just-built env :)

> +
> +# Paraphrasing http://bugs.gnu.org/34488#8:
> +# POSIX requires that sh started with an inherited ignored SIGPIPE must
> +# silently ignore all attempts from within the shell to restore SIGPIPE
> +# handling to child processes of the shell:
> +#
> +#    $ (trap '' PIPE; bash -c 'trap - PIPE; seq inf | head -n1')
> +#    1
> +#    seq: write error: Broken pipe
> +#
> +# With 'env --default-signal=PIPE', the signal handler can be reset to its
> +# default.
> +
> +# Baseline Test
> +# -------------
> +# Ensure this results in a "broken pipe" error (the first 'trap'
> +# sets SIGPIPE to ignore, and the second 'trap' becomes a no-op instead
> +# of resetting SIGPIPE to its default). Upon a SIGPIPE 'seq' will not be
> +# terminated, instead its write(2) call will return an error.
> +(trap '' PIPE; sh -c 'trap - PIPE; seq 999999 2>err1t | head -n1 > out1')
> +
> +# The exact broken pipe message depends on the operating system, just ensure
> +# there was a 'write error' message in stderr:
> +sed 's/^\(seq: write error:\) .*/\1/' err1t > err1 || framework_failure_
> +
> +printf "1\n" > exp-out || framework_failure_
> +printf "seq: write error:\n" > exp-err1 || framework_failure_
> +
> +compare exp-out out1 || framework_failure_
> +compare exp-err1 err1 || framework_failure_

Nice setup.

> +
> +
> +# env test
> +# --------
> +# With env resetting the signal handler to its defaults, there should be no
> +# error message (because the default SIGPIPE action is to terminate the
> +# 'seq' program):
> +(trap '' PIPE;
> + env --default-signal=PIPE \
> +    sh -c 'trap - PIPE; seq 999999 2>err2 | head -n1 > out2')

Perhaps you could also test:

(trap '' PIPE; env --default-signal=PIPE seq 999999 2>err3 | head -n1 >
out3)

But in general I like the patch.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #26 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 Assaf Gordon <assafgordon <at> gmail.com>
Cc: 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Fri, 15 Feb 2019 14:42:17 -0800

On 2/15/19 7:49 AM, 積丹尼 Dan Jacobson wrote:
> Well the user thinks "hey I cut short 5 lines, 45 lines, 495 lines, and
> then one I got a job at a big company and cut short 4995 lines and got
> this error message just when the boss was looking."

I'm afraid I'll have to disagree on this one. This is a generic problem 
for any program that writes to standard output, and is not peculiar to 
'sort'. The 'sort' documentation is not the right place to document this 
issue, just as it's not the right place to document what happens when 
you type control-C to interrupt a sort.

Message #29 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Assaf Gordon <assafgordon <at> gmail.com>, Eric Blake <eblake <at> redhat.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 17 Feb 2019 00:56:13 +0100

On 2/15/19 10:40 PM, Assaf Gordon wrote:
>> $ seq 9999 | env --default-signal PIPE sort -n | sed 5q | wc -l
>> 5
> 
> That is a nice idea, I could've used it myself couple of times.
> 
> Attached a suggested patch.
> If this seems like a good direction, I'll complete it with NEWS/docs/etc.

>  src/env.c                        | 90 +++++++++++++++++++++++++++++++++++++++-

That's quite a lot of new code.

What about a new program ... quick shot (and maybe an unlucky name): 'trap' ?

Have a nice day,
Berny

Message #32 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 34488 <at> debbugs.gnu.org, Assaf Gordon <assafgordon <at> gmail.com>,
 Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#34488: Add sort --limit,
 or document workarounds for sort|head error messages
Date: Sun, 17 Feb 2019 15:24:38 +0800

(I recall I heard about 50 years ago when pipe buffers first came to
Unix they were supposed to be invisible to the user...)

Message #35 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Eric Blake <eblake <at> redhat.com>, 積丹尼 Dan Jacobson
 <jidanni <at> jidanni.org>, 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 17 Feb 2019 09:28:14 -0700

On 2019-02-16 4:56 p.m., Bernhard Voelker wrote:
> On 2/15/19 10:40 PM, Assaf Gordon wrote:
>>> $ seq 9999 | env --default-signal PIPE sort -n | sed 5q | wc -l

>>   src/env.c                        | 90 +++++++++++++++++++++++++++++++++++++++-
> 
> That's quite a lot of new code.
> 
> What about a new program ... quick shot (and maybe an unlucky name): 'trap' ?
> 

I don't mind either way (env feature or new program).

"trap" will get mixed-up with the shell's built-in command.
How about "untrap" (because the goal is to undo the 'trap' command),
and also there's no "untrap" executable name in debian, so no name 
conflicts?

will send an updated patch later today.

-assaf

Message #38 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Assaf Gordon <assafgordon <at> gmail.com>,
 Bernhard Voelker <mail <at> bernhard-voelker.de>, Eric Blake <eblake <at> redhat.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 17 Feb 2019 12:12:48 -0800

Assaf Gordon wrote:
> I don't mind either way (env feature or new program).

This should be a new feature of 'nohup' not 'env', as 'nohup' is already about 
signal handling.  I don't see a need for a new program.

Message #41 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>,
 Bernhard Voelker <mail <at> bernhard-voelker.de>, Eric Blake <eblake <at> redhat.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 17 Feb 2019 13:31:26 -0700

Hello,

On 2019-02-17 1:12 p.m., Paul Eggert wrote:
> Assaf Gordon wrote:
>> I don't mind either way (env feature or new program).
> 
> This should be a new feature of 'nohup' not 'env', as 'nohup' is already 
> about signal handling.  I don't see a need for a new program.

With 'nohup' I don't think there will be an easy (or at least intuitive
way) to 'untrap' SIGPIPE without affecting the output: STDOUT will be 
redirected to 'nohup.out' automatically (unless we add more options like 
"--no-redirect").

Example:

    env -C /foo/bar PROGRAM            ## only change directory
    env --default-signal=PIPE PROGRAM  ## only untrap SIGPIPE
    env -i PROGRAM                     ## only empty environment

but

    nohup --default-signal=PIPE PROGRAM

Will untrap SIGPIPE *and* SIGHUP *and* redirect stdout to a file.
So we'll need to add:

  nohup --no-redirect-stdout --default-signal=PIPE PROGRAM

Also,
nohup's manual pages warns:
   "NOTE:  your  shell  may  have  its own version of nohup, which
    usually supersedes the version described here.  Please refer to
    your shell's documentation for details about the options it
    supports."

And if there is a built-in "nohup", it will confuse users who want to
use our new feature (and then more support questions, and we have to
explain how to use "env nohup" or "\nohup".

What do you think?

-assaf

Message #44 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Assaf Gordon <assafgordon <at> gmail.com>,
 Bernhard Voelker <mail <at> bernhard-voelker.de>, Eric Blake <eblake <at> redhat.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 17 Feb 2019 13:00:24 -0800

You make good points about nohup. Still, it's too bad that we'd have to add a 
new command for such a trivial thing.

Perhaps it'd be better to overload 'env' instead, as you proposed earlier. After 
all, env is already being used for another little environmental thing (namely 
changing directories), and if we find future needs for yet other little things 
(running with a different umask, say) we can put them under 'env' as well.

Message #47 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Assaf Gordon <assafgordon <at> gmail.com>,
 Bernhard Voelker <mail <at> bernhard-voelker.de>, Eric Blake <eblake <at> redhat.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 17 Feb 2019 17:52:02 -0800

On 17/02/19 13:00, Paul Eggert wrote:
> You make good points about nohup. Still, it's too bad that we'd have to add a 
> new command for such a trivial thing.
> 
> Perhaps it'd be better to overload 'env' instead, as you proposed earlier. After 
> all, env is already being used for another little environmental thing (namely 
> changing directories), and if we find future needs for yet other little things 
> (running with a different umask, say) we can put them under 'env' as well.

+1

Message #50 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 34488 <at> debbugs.gnu.org, Assaf Gordon <assafgordon <at> gmail.com>,
 Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 17 Feb 2019 17:53:48 -0800

On 16/02/19 23:24, 積丹尼 Dan Jacobson wrote:
> (I recall I heard about 50 years ago when pipe buffers first came to
> Unix they were supposed to be invisible to the user...)

Right. A lot of folks don't understand/handle them fully though:
https://www.pixelbeat.org/programming/sigpipe_handling.html

Message #53 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>, Assaf Gordon <assafgordon <at> gmail.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 17 Feb 2019 18:00:49 -0800

On 15/02/19 14:11, Eric Blake wrote:
> On 2/15/19 3:40 PM, Assaf Gordon wrote:
>> Helo,
>>
>> On 2019-02-15 8:20 a.m., Eric Blake wrote:
>>> On 2/15/19 8:43 AM, 積丹尼 Dan Jacobson wrote:
>>>> sort: write failed: 'standard output': Broken pipe
>>>> sort: write error
>> [...]
>>> Perhaps coreutils should teach 'env' a command-line option to forcefully
>>> reset SIGPIPE back to default behavior [...]   If we
>>> did that, then even if your sh is started with SIGPIPE ignored (so that
>>> the shell itself can't restore default behavior), you could do this
>>> theoretical invocation:
>>>
>>> $ seq 9999 | env --default-signal PIPE sort -n | sed 5q | wc -l
>>> 5
>>
>> That is a nice idea, I could've used it myself couple of times.
>>
>> Attached a suggested patch.
>> If this seems like a good direction, I'll complete it with NEWS/docs/etc.
> 
> Would we also want an easy way to ignore signals? That's a bit less of
> an issue, since you can use 'trap "" $SIG' in the shell; but having the
> symmetry in env may be nice (especially since using 'trap' is asymmetric
> in that you can't force the shell to un-ignore an inherited ignored signal).

I agree that ignore would be nice to add also.

>> Usage is:
>>     env --default-signal=PIPE
>>     env -P     ##shortcut to reset SIGPIPE

BSD has -P for different reasons, so I would avoid that conflict

thanks a lot for working on this guys.
Pádraig

Message #56 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>, 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>, 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 17 Feb 2019 18:20:19 -0800

On 15/02/19 07:20, Eric Blake wrote:
> Except that POSIX has the nasty requirement that sh started with an
> inherited ignored SIGPIPE must silently ignore all attempts from within
> the shell to restore SIGPIPE handling to child processes of the shell:
> 
> $ (trap '' PIPE; bash -c 'trap - PIPE; \
>    seq 9999 | sort -n | sed 5q | wc -l')
> 5
> sort: write failed: 'standard output': Broken pipe
> sort: write error

> You HAVE to use some other intermediate program if you want to override
> an inherited ignored SIGPIPE in sh into an inherited default-behavior
> SIGPIPE in sort.

Should we also propose to POSIX to allow trap to specify default?
Maybe `trap 0 PIPE` or similar?

Message #59 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>,
 Paul Eggert <eggert <at> cs.ucla.edu>, Bernhard Voelker
 <mail <at> bernhard-voelker.de>, Eric Blake <eblake <at> redhat.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Mon, 18 Feb 2019 02:46:59 -0700

[Message part 1 (text/plain, inline)]

Hello,

Thanks for all comments (on and off list).
Attached an updated patch with documentation.

The supported options are:

 --default-signal[=SIG]  reset signal SIG to its default signal handler.
                         without SIG, all known signals are included.
                         multiple signals can be comma-separated.
 --ignore-signal[=SIG]   set signal SIG to be IGNORED.
                         without SIG, all known signals are included.
                         multiple signals can be comma-separated.
 -p                      same as --default-signal=PIPE

(lower-case "-p" as to not conflict with BSD, but of course can be
changed to another letter).

The new 'env-signal-handler.sh' test passes on GNU/linux, non-gnu/linux
(alpine), and Free/Open/Net BSD.

Comments very welcomed,
 - assaf

[0001-env-new-options-p-default-signal-SIG-ignore-signal-S.patch (text/x-patch, attachment)]

Message #62 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Mon, 18 Feb 2019 10:02:40 -0600

[Message part 1 (text/plain, inline)]

On 2/17/19 8:20 PM, Pádraig Brady wrote:
> On 15/02/19 07:20, Eric Blake wrote:
>> Except that POSIX has the nasty requirement that sh started with an
>> inherited ignored SIGPIPE must silently ignore all attempts from within
>> the shell to restore SIGPIPE handling to child processes of the shell:
>>
>> $ (trap '' PIPE; bash -c 'trap - PIPE; \
>>    seq 9999 | sort -n | sed 5q | wc -l')
>> 5
>> sort: write failed: 'standard output': Broken pipe
>> sort: write error
> 
>> You HAVE to use some other intermediate program if you want to override
>> an inherited ignored SIGPIPE in sh into an inherited default-behavior
>> SIGPIPE in sort.
> 
> Should we also propose to POSIX to allow trap to specify default?

That's what "trap - PIPE" is already supposed to do, except that POSIX
has the odd requirement that a signal that was inherited ignored cannot
be reset to default.

> Maybe `trap 0 PIPE` or similar?

Alas, bash has already defined that to mean the same as 'trap - EXIT PIPE'.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #65 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>, 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>, 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sat, 23 Feb 2019 21:32:02 -0800

On 18/02/19 08:02, Eric Blake wrote:
> On 2/17/19 8:20 PM, Pádraig Brady wrote:
>> On 15/02/19 07:20, Eric Blake wrote:
>>> Except that POSIX has the nasty requirement that sh started with an
>>> inherited ignored SIGPIPE must silently ignore all attempts from within
>>> the shell to restore SIGPIPE handling to child processes of the shell:
>>>
>>> $ (trap '' PIPE; bash -c 'trap - PIPE; \
>>>    seq 9999 | sort -n | sed 5q | wc -l')
>>> 5
>>> sort: write failed: 'standard output': Broken pipe
>>> sort: write error
>>
>>> You HAVE to use some other intermediate program if you want to override
>>> an inherited ignored SIGPIPE in sh into an inherited default-behavior
>>> SIGPIPE in sort.
>>
>> Should we also propose to POSIX to allow trap to specify default?
> 
> That's what "trap - PIPE" is already supposed to do, except that POSIX
> has the odd requirement that a signal that was inherited ignored cannot
> be reset to default.
> 
>> Maybe `trap 0 PIPE` or similar?
> 
> Alas, bash has already defined that to mean the same as 'trap - EXIT PIPE'.

Fair enough, but do we agree that it would be good
to have functionality in the shell with some similar syntax
that resets the handler to system default?

cheers,
Pádraig

Message #68 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Assaf Gordon <assafgordon <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
 Bernhard Voelker <mail <at> bernhard-voelker.de>, Eric Blake <eblake <at> redhat.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sat, 23 Feb 2019 22:13:41 -0800

[Message part 1 (text/plain, inline)]

On 18/02/19 01:46, Assaf Gordon wrote:
> Hello,
> 
> Thanks for all comments (on and off list).
> Attached an updated patch with documentation.
> 
> The supported options are:
> 
>   --default-signal[=SIG]  reset signal SIG to its default signal handler.
>                           without SIG, all known signals are included.
>                           multiple signals can be comma-separated.
>   --ignore-signal[=SIG]   set signal SIG to be IGNORED.
>                           without SIG, all known signals are included.
>                           multiple signals can be comma-separated.
>   -p                      same as --default-signal=PIPE
> 
> (lower-case "-p" as to not conflict with BSD, but of course can be
> changed to another letter).
> 
> The new 'env-signal-handler.sh' test passes on GNU/linux, non-gnu/linux
> (alpine), and Free/Open/Net BSD.
> 
> Comments very welcomed,

Attached is a patch to be squashed in to:

  Process the same signals as kill -l
  Output whether action failed or not
  Don't run sigaction(..set..) if get failed

I'm not that enthusiastic about the -p
since it treats PIPE specially here,
and it's not special from env's point of view.

cheers,
Pádraig

[env-default-fixes.patch (text/x-patch, attachment)]

Message #71 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: Eric Blake <eblake <at> redhat.com>, Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Pádraig Brady <P <at> draigBrady.com>, 34488 <at> debbugs.gnu.org,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 24 Feb 2019 10:33:47 -0800

Thanks for doing all that. Although Pádraig is not enthusiastic about a shortcut 
like -p, I'm a bit warmer to it, as it's an important special case to fix a wart 
in POSIX. No big deal either way.

The documentation should mention that SIGCHLD is special, in that 
--ignore-signal=CHLD might have no effect (POSIX says it's unspecified).

The documentation should say what happens if mutually-contradictory options are 
specified, e.g., '--default-signal=INT --ignore-signal=INT'. Presumably they are 
processed left-to-right, as is traditional for 'env' with contradictory operands.

There should be options --block-signal[=SIG], --unblock-signal[=SIG], and 
--setmask-signal[=SIG] that affect the signal mask, which is also inherited by 
the child. These can be implemented via pthread_sigmask.

The documentation should echo this suggestion in 
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html>: "many 
existing applications wrongly assume that they start with certain signals set to 
the default action and/or unblocked.... Therefore, it is best not to block or 
ignore signals across execs without explicit reason to do so, and especially not 
to block signals across execs of arbitrary (not closely cooperating) programs."

Message #74 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eric Blake <eblake <at> redhat.com>, Assaf Gordon <assafgordon <at> gmail.com>,
 Pádraig Brady <P <at> draigBrady.com>,
 Bernhard Voelker <mail <at> bernhard-voelker.de>, 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit,
 or document workarounds for sort|head error messages
Date: Mon, 25 Feb 2019 02:40:41 +0800

Thanks for working on this guys, hopefully users will one day no longer
be faced with (yes, seemingly) random errors.
$ ls -l | sed 2!d
drwxr-xr-x 14 jidanni jidanni      4096 2016-12-24  AndroidMisc
$ ls -l | sed 2q
total 157780
drwxr-xr-x 14 jidanni jidanni      4096 2016-12-24  AndroidMisc
ls: write error: Broken pipe

Message #77 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Mon, 25 Feb 2019 08:01:44 -0600

On 2/23/19 11:32 PM, Pádraig Brady wrote:

>>>> You HAVE to use some other intermediate program if you want to override
>>>> an inherited ignored SIGPIPE in sh into an inherited default-behavior
>>>> SIGPIPE in sort.
>>>
>>> Should we also propose to POSIX to allow trap to specify default?
>>
>> That's what "trap - PIPE" is already supposed to do, except that POSIX
>> has the odd requirement that a signal that was inherited ignored cannot
>> be reset to default.
>>
>>> Maybe `trap 0 PIPE` or similar?
>>
>> Alas, bash has already defined that to mean the same as 'trap - EXIT PIPE'.
> 
> Fair enough, but do we agree that it would be good
> to have functionality in the shell with some similar syntax
> that resets the handler to system default?

Worth asking on the bash list to see if Chet has any interest in such an
extension (POSIX is reluctant to specify something that doesn't have
existing implementation practice).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Message #80 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Eric Blake <eblake <at> redhat.com>, Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Pádraig Brady <P <at> draigBrady.com>, 34488 <at> debbugs.gnu.org,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Mon, 25 Feb 2019 18:15:03 -0700

[Message part 1 (text/plain, inline)]

Hello,

Thanks for all comments.

On 2019-02-24 11:33 a.m., Paul Eggert wrote:
> Thanks for doing all that. Although Pádraig is not enthusiastic about a 
> shortcut like -p, I'm a bit warmer to it, as it's an important special 
> case to fix a wart in POSIX. No big deal either way.

For now I kept "-p", can be removed later of course.
The first patch includes Pádraig's recent suggestions (slightly modified).

> The documentation should mention that SIGCHLD is special [...]

> The documentation should say what happens if mutually-contradictory 
> options are specified, [...]

> The documentation should echo this suggestion in 
> <http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html>: 

I've added those, and I welcome all improvements suggestion to 
grammar/phrasing/etc.

> There should be options --block-signal[=SIG], --unblock-signal[=SIG],
> and --setmask-signal[=SIG] that affect the signal mask, which is also
> inherited by the child. These can be implemented via pthread_sigmask.

The second patch adds these new options (separated to ease review).
As for documentation - I'm not sure what to add beyond the basic
option description. When should these be used?

A third small patch adds "env ---list-signal-actions" and
"env --list-blocked-signals" - to ease diagnostics.
Might be worth adding for completeness (e.g., for users who
need to somehow know if SIGPIPE is being ignored by the shell
or not):

    $ ( trap '' PIPE && src/env --list-signal-actions )
    PIPE       (13): ignore

Comments very welcomed,
 - assaf

[0001-env-new-options-p-default-signal-SIG-ignore-signal-S.patch (text/x-patch, attachment)]

[0002-env-add-block-unblock-setmask-signal-SIG-options.patch (text/x-patch, attachment)]

[0003-env-add-list-blocked-signals-list-signal-actions-opt.patch (text/x-patch, attachment)]

Message #83 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Assaf Gordon <assafgordon <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 34488 <at> debbugs.gnu.org, Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Eric Blake <eblake <at> redhat.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Mon, 25 Feb 2019 22:35:19 -0800

[Message part 1 (text/plain, inline)]

Thanks for doing all that.
I've attached a few changes:

- spelling fixes
- usage() clarified/reordered
- ensure sigset_t are initialized
- Don't setprocmask() unless specified
- Simplified SETMASK_SIGNAL_OPTION handling
- The test missed `env` as a prerequisite
- The test was slow/spun cpu, so used sleep instead of seq
- Used $SHELL in case sh didn't support trap

I see that the last signal that `kill -l` lists is not included.
I think we should be processing SIGNUM_BOUND also?

cheers,
Pádraig

[env-signal-fixes.patch (text/x-patch, attachment)]

Message #86 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 3 Mar 2019 15:36:12 -0800

[Message part 1 (text/plain, inline)]

On 25/02/19 22:35, Pádraig Brady wrote:
> Thanks for doing all that.
> I've attached a few changes:
> 
> - spelling fixes
> - usage() clarified/reordered
> - ensure sigset_t are initialized
> - Don't setprocmask() unless specified
> - Simplified SETMASK_SIGNAL_OPTION handling
> - The test missed `env` as a prerequisite
> - The test was slow/spun cpu, so used sleep instead of seq
> - Used $SHELL in case sh didn't support trap
> 
> I see that the last signal that `kill -l` lists is not included.
> I think we should be processing SIGNUM_BOUND also?

An additional patch attached to replace --list-signal-actions
with --list-ignored-signals.  This is simpler, and more symmetric
with the other options. Also the extra output was moot I think
since handlers are reset upon exec. For completeness the transitions are:

upon fork
  default -> default
  handled -> handled
  ignored -> ignored
  pending -> cleared
  blocked -> blocked

upon exec
  default -> default
  handled -> default
  ignored -> ignored
  pending -> pending
  blocked -> blocked

shell has additional rules:
  can't unignore
  handled -> default in subshell

I'll squash this into yours, before commit.

cheers,
Pádraig

[env-list-ignored.patch (text/x-patch, attachment)]

Message #89 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 3 Mar 2019 16:07:39 -0800

[Message part 1 (text/plain, inline)]

On 03/03/19 15:36, Pádraig Brady wrote:
> On 25/02/19 22:35, Pádraig Brady wrote:
>> Thanks for doing all that.
>> I've attached a few changes:
>>
>> - spelling fixes
>> - usage() clarified/reordered
>> - ensure sigset_t are initialized
>> - Don't setprocmask() unless specified
>> - Simplified SETMASK_SIGNAL_OPTION handling
>> - The test missed `env` as a prerequisite
>> - The test was slow/spun cpu, so used sleep instead of seq
>> - Used $SHELL in case sh didn't support trap
>>
>> I see that the last signal that `kill -l` lists is not included.
>> I think we should be processing SIGNUM_BOUND also?
> 
> An additional patch attached to replace --list-signal-actions
> with --list-ignored-signals.  This is simpler, and more symmetric
> with the other options. Also the extra output was moot I think
> since handlers are reset upon exec

I've locally adjusted the NEWS/texi for that patch also.
I've a local patch to include SIGNUM_BOUND which I won't spam the list with.

Attached is a patch to remove the -p and --set-mask options,
which I've a light preference for.
I'll think some more about it.

cheers,
Pádraig

[env-remove-shortcuts.patch (text/x-patch, attachment)]

Message #92 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 3 Mar 2019 16:59:28 -0800

[Message part 1 (text/plain, inline)]

On 03/03/19 16:07, Pádraig Brady wrote:
> On 03/03/19 15:36, Pádraig Brady wrote:
>> On 25/02/19 22:35, Pádraig Brady wrote:
>>> Thanks for doing all that.
>>> I've attached a few changes:
>>>
>>> - spelling fixes
>>> - usage() clarified/reordered
>>> - ensure sigset_t are initialized
>>> - Don't setprocmask() unless specified
>>> - Simplified SETMASK_SIGNAL_OPTION handling
>>> - The test missed `env` as a prerequisite
>>> - The test was slow/spun cpu, so used sleep instead of seq
>>> - Used $SHELL in case sh didn't support trap
>>>
>>> I see that the last signal that `kill -l` lists is not included.
>>> I think we should be processing SIGNUM_BOUND also?
>>
>> An additional patch attached to replace --list-signal-actions
>> with --list-ignored-signals.  This is simpler, and more symmetric
>> with the other options. Also the extra output was moot I think
>> since handlers are reset upon exec
> 
> I've locally adjusted the NEWS/texi for that patch also.
> I've a local patch to include SIGNUM_BOUND which I won't spam the list with.
> 
> Attached is a patch to remove the -p and --set-mask options,
> which I've a light preference for.
> I'll think some more about it.

Attached is a patch to combine the two --list options
to a single --list-signal-handling option.
This also doesn't exit, and so is more useful as
users can add --list-signal to their env commands
to diagnose signal handling.  One can easily use `true`
as the command to get the original list only functionality.

A summary of the all signal options in my local set now is:

  --block-signal[=SIG]    block delivery of SIG signal(s) to COMMAND
  --unblock-signal[=SIG]  unblock delivery of SIG signal(s) to COMMAND
  --default-signal[=SIG]  reset handling of SIG signal(s) to the default
  --ignore-signal[=SIG]   set handling of SIG signals(s) to do nothing
  --list-signal-handling  list non default signal handling to stderr

cheers,
Pádraig

[env-single-list.patch (text/x-patch, attachment)]

Message #95 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Sun, 3 Mar 2019 17:47:24 -0800

[Message part 1 (text/plain, inline)]

On 03/03/19 16:59, Pádraig Brady wrote:
> A summary of the all signal options in my local set now is:
> 
>   --block-signal[=SIG]    block delivery of SIG signal(s) to COMMAND
>   --unblock-signal[=SIG]  unblock delivery of SIG signal(s) to COMMAND
>   --default-signal[=SIG]  reset handling of SIG signal(s) to the default
>   --ignore-signal[=SIG]   set handling of SIG signals(s) to do nothing
>   --list-signal-handling  list non default signal handling to stderr

I think we might be also able to remove --unblock-signal,
and just have --default-signal.

I.E. I don't think one would want to set default signal handling,
but leave a signal blocked?  Also I don't think one would
want to unblock a signal, but leave it ignored?
At least not and the level of env just exec()ing a program.
Anyway if those weird cases are needed, they can be achieved
by combining the options.

The attached does that, leaving us with:

--block-signal[=SIG]    block delivery of SIG signal(s) to COMMAND
--default-signal[=SIG]  reset handling of SIG signal(s) to the default
--ignore-signal[=SIG]   set handling of SIG signals(s) to do nothing
--list-signal-handling  list non default signal handling to stderr

cheers,
Pádraig.

[env-no-unblock.patch (text/x-patch, attachment)]

Message #98 received at 34488 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Pádraig Brady <P <at> draigBrady.com>,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 34488 <at> debbugs.gnu.org
Subject: Re: bug#34488: Add sort --limit, or document workarounds for
 sort|head error messages
Date: Thu, 28 Mar 2019 12:33:23 -0600

tags 34488 fixed
close 34488
stop

Hello,

The original request of "sort --limit" resulted in
an improved "env" with options new options,
which was included in the recent version 8.31.

I'm therefor closing this item.

-assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.