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
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
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
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
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
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
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
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?
>>
>>
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:
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
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,
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
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
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.
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;
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
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
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
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
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
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.
On 2019-02-16 4:56 p.m., Bernhard Voelker wrote:
On 2/15/19 10:40 PM, Assaf Gordon wrote:
$ seq | 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
(I recall I heard about 50 years ago when pipe buffers first came to
Unix they were supposed to be invisible to the user...)
On 2/15/19 10:40 PM, Assaf Gordon wrote:
>> $ seq | 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.
>
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
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
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
> "EB" == Eric Blake 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
> "AG" == Assaf Gordon 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
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 9; do seq $i|sort -n|sed 5q|wc -l; done
5
5
5
5
sort: write
On 2/15/19 8:43 AM, 積丹尼 Dan Jacobson wrote:
> Things start out cheery, but quickly get ugly,
>
> $ for i in 9 99 999 9; 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
Things start out cheery, but quickly get ugly,
$ for i in 9 99 999 9; 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
32 matches
Mail list logo
