Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed outputs

2022-11-29 Thread Carl Edquist via GNU coreutils General Discussion
On Tue, 29 Nov 2022, Arsen Arsenović wrote: The issue here isn't the compilers hanging, it's tee living longer than all the compilers do because it's stdin doesn't EOF (it'd be preferable for it to only live as long as the last of the compilers). I can imagine attempting to implement this

Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed outputs

2022-11-29 Thread Pádraig Brady
On 29/11/2022 21:48, Carl Edquist wrote: Or perhaps when you mention "inducing SIGPIPE", you are referring to how tail(1) does things currently (when it detects a broken output), by attempting raise(SIGPIPE) followed by exit(EXIT_FAILURE). Yes this is what I was alluding to. It seems this is

Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed outputs

2022-11-29 Thread Carl Edquist via GNU coreutils General Discussion
On Tue, 29 Nov 2022, Pádraig Brady wrote: On 29/11/2022 17:32, Carl Edquist wrote: ... If this kind of detect-broken-output-pipe logic were added to filter utils generally, the above example (with 4 cats) would return to the shell immediately. Right. Thanks for discussing the more

Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed outputs

2022-11-29 Thread Arsen Arsenović
William Bader writes: > For the case of testing two compile runs, could you use something like the > bash > command below (replacing 'sleep ...' with 'gcc ...')? The issue here isn't the compilers hanging, it's tee living longer than all the compilers do because it's stdin doesn't EOF (it'd

Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed outputs

2022-11-29 Thread Arsen Arsenović
Pádraig Brady writes: > Right. Thanks for discussing the more general pattern. > I.e. that SIGPIPE doesn't cascade back up the pipeline, > only upon attempted write to the pipe. > So it's not really a tee issue, more of a general pattern. > > So it wouldn't be wrong to add this to tee (by

Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed outputs

2022-11-29 Thread William Bader
For the case of testing two compile runs, could you use something like the bash command below (replacing 'sleep ...' with 'gcc ...')? (timeout 10 sleep 2 ; echo a) & (timeout 2 sleep 10 ; echo b) & echo c ; wait ; echo d From:

[PATCH] numfmt: support new ronna, quetta SI prefixes

2022-11-29 Thread Pádraig Brady
Add support for larger quantities, as voted for in Nov 2022 by the BIPM: https://www.bipm.org/en/cgpm-2022/resolution-3 This now allows: $ numfmt --from=si --to=iec 2000R 1.6Q * src/numfmt.c: Increase limits from 999Y to 999Q. * tests/misc/numfmt.pl: Adjust accordingly. * doc/coreutils.texi

Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed outputs

2022-11-29 Thread Pádraig Brady
On 29/11/2022 17:32, Carl Edquist wrote: Oh and, ... On Mon, 28 Nov 2022, Pádraig Brady wrote: I'm presuming the input generator is depending on the compiler runs (written to by tee) to exit cleanly, before exiting / generating more? Hence the hangs? If that was the case then there still

Re: [PATCH] tee: Add --pipe-check to allow instantly detecting closed outputs

2022-11-29 Thread Carl Edquist via GNU coreutils General Discussion
Hi all, On Mon, 28 Nov 2022, Arsen Arsenović wrote: Pádraig Brady writes: Trying to understand your use case better, ... The bug we observed is that on occasion, for instance when running with a tty, or with a script that (for some reason) has a pipe on stdin, the tee-based "compiler"