bug#34522: Bug in --help command of comm --help
Examples: comm -12 file1 file2 Print only lines present in both file1 and file2. comm -3 file1 file2 Print lines in file1 not in file2, and vice versa. comm -3 prints lines that are unique to both file1 and file2 in separate columns. comm *-23* prints the lines that are in file1 and not in file2. I hope the correction will be made soon enough. Regards, Bhargav.
bug#34490: console the user that his -n in sort --debug -n was seen
On 16/02/19 23:28, 積丹尼 Dan Jacobson wrote: >> "PB" == Pádraig Brady writes: > PB> Fair point. I'm thinking of this extra qualification: > > PB> sort: text ordering performed using ‘en_IE.UTF-8’ sorting rules > Maybe say 'LC_CTYPE=en_IE.UTF-8' > sorting rules > > PB> sort: text ordering performed using simple byte comparison > > sort: text ordering performed using simple byte (LC_CTYPE=C) comparison > or something like that. That's probably more confusing to the user, especially as one doesn't generally explicitly set LC_CTYPE. I'll go with my clarification. thanks, Pádraig
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
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 | 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?
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
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 | 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
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
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
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
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
bug#33468: A bug with yes and --help
On 15/02/19 10:32, Assaf Gordon wrote: > Hello Eric and all, > > > Thanks for the quick and detailed review. > I've amended all the issues you mentioned. > > On 2019-02-13 8:20 p.m., Eric Blake wrote: >>> 15 files changed, 46 insertions(+), 141 deletions(-) >> >> Nice diffstat. > > These are of course Bernhard's improvements, > I just did the testing (and some minor things). > >>> diff --git a/NEWS b/NEWS >> >> Is "argument" better than "option" here? Or, maybe: >> >> now always process --help and --version options, regardless of any other >> arguments present before any optinoal -- end-of-options marker. > > I've used your phrasing, and also separated "nohup" from the rest > of the programs, as it does not accept --help/--version anywhere, > just as first arguments. > > Attached updated patches, with tests. > > comments welcomed, > - assaf > > P.S. > There is at least one change in behavior, not sure if this is > bad enough to be a regression or doesn't really matter: > >$ yes-OLD me -- --help | head -n1 >me -- --help > >$ yes-NEW me -- --help | head -n1 >me --help I wouldn't worry about that. If it could be controlled by POSIXLY_CORRECT all the better, but still not worth worrying about. It would be appropriate for a test, at least for documentation. this is looks ready to land. thanks! Pádraig
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
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.
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
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
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
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.
bug#34488: Add sort --limit, or document workarounds for sort|head error messages
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 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
