On Thu, 18 Apr 2024, Zachary Santer wrote:
On Wed, Mar 20, 2024 at 4:54 AM Carl Edquist wrote:
However, if stdbuf's magic env vars are exported in your shell (either
by doing a trick like 'export $(env -i stdbuf -oL env)', or else more
simply by first starting a new shell with 'stdbuf -oL
On Tue, 19 Mar 2024, Zachary Santer wrote:
On Tue, Mar 19, 2024 at 1:24 AM Kaz Kylheku wrote:
But what tee does is set up _IONBF on its output streams,
including stdout.
So it doesn't buffer at all. Awesome. Nevermind.
Yay! :D
And since tee uses fwrite to copy whatever input is
On Mon, 11 Mar 2024, Zachary Santer wrote:
On Mon, Mar 11, 2024 at 7:54 AM Carl Edquist
wrote:
(In my coprocess management library, I effectively run every coproc
with --output=L by default, by eval'ing the output of 'env -i stdbuf
-oL env', because most of the time for a coprocess,
On Sun, 10 Mar 2024, Zachary Santer wrote:
On Sun, Mar 10, 2024 at 4:36 PM Carl Edquist wrote:
Out of curiosity, do you have an example command line for your use case?
My use for 'stdbuf --output=L' is to be able to run a command within a
bash coprocess.
Oh, cool, now you're talking! ;)
Hi Zack,
This sounds like a potentially useful feature (it'd probably belong with a
corresponding new buffer mode in setbuf(3)) ...
Filenames should be passed between utilities in a null-terminated
fashion, because the null byte is the only byte that can't appear within
one.
Out of
On Tue, 13 Dec 2022, Pádraig Brady wrote:
Thanks to both of you for working through the details on this. This does
seem like a useful feature, and would be appropriate to add.
A summarized patch set would be appreciated at this stage, thanks.
Re HAVE_INOTIFY, that's really a proxy for a
On Mon, 12 Dec 2022, Arsen Arsenović wrote:
Hi Carl,
Carl Edquist writes:
[2. text/x-diff; 0001-tee-only-fstat-outputs-if-pipe_check-is-active.patch]...
[3. text/x-diff;
0002-tee-skip-pipe-checks-if-input-is-always-ready-for-re.patch]...
Thanks for writing these, and the other patches.
On Mon, 12 Dec 2022, Arsen Arsenović wrote:
Hi Rob,
Rob Landley writes:
This sort of thing is why I added -i to toybox's "timeout" command:
-i Only kill for inactivity (restart timeout when command produces output)
It runs the command's stdout through a pipe and does a poll() with
On Fri, 9 Dec 2022, Carl Edquist wrote:
On Fri, 9 Dec 2022, Arsen Arsenović wrote:
Originally i had imagined (or hoped) that this broken-pipe detection
could also be used for sockets (that was how the issue came up for
me), but it seems the semantics for sockets are different than for
Hi Pádraig,
Getting back to this portability question:
On Fri, 2 Dec 2022, Pádraig Brady wrote:
Anyway if it's possible just to use poll(2) (the system one, not the
gnulib replacement), that might simplify the portability logic.
Yes it would be better to use poll() if possible,
and that's
On Fri, 9 Dec 2022, Arsen Arsenović wrote:
Similar to the situation here, i was seeing things annoyingly look like
they are still 'alive' longer than they ought to be when providing
input from the terminal.
Huh, I never tried that, honestly.
Here is a simple example:
exec 3<>
On Thu, 8 Dec 2022, Arsen Arsenović wrote:
Apologies for my absence, Tuesdays and Wednesdays are long workdays for
me.
No need for apologies - I feel like i am the one who should apologize for
my high volume of email to the list. People have lives after all! :)
The timing of this thread
Hi Arsen, thanks for your feedback!
On Tue, 6 Dec 2022, Arsen Arsenović wrote:
The stubborn part of me might say, for platforms that do not natively
support poll(2), we could simply leave out support for this feature.
If that's not acceptable, we could add a select(2)-based fallback for
On Fri, 2 Dec 2022, Arsen Arsenović wrote:
I'm concerned with adding such a behavior change by default still. I
can imagine this "lifetime extension" properly having been relied on in
the last many decades it has been around for ;)
That's fair! :) I'd be curious to hear about a use-case
PS:
On Fri, 2 Dec 2022, Carl Edquist wrote:
On the topic of implementation - I was thinking more about a general
solution for filter utils, and I am thinking the key thing is to provide
a replacement (wrapper) for read(2), that polls two fds together (one
input and one ouput), with no
On Wed, 30 Nov 2022, Arsen Arsenović wrote:
Carl Edquist writes:
It sounds like one way or another you want to copy your endless but
intermittent input to multiple output pipes, but you want to quit as
soon as all the output pipes become broken.
Precisely. The most important requirement
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
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
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"
On Wed, 21 Apr 2021, Carl Edquist wrote:
Thanks Pádraig for the thoughtful reply!
You bring up some good points, which for the sake of interesting
discussion i'd like to follow up on also. (Maybe later this week...)
So to follow up - i don't have any action items here, just some details
On Tue, 20 Apr 2021, p...@draigbrady.com wrote:
> One can also implement this functionality with the DSU pattern like:
>
> nlargest=10
> find . -printf '%s\t%p\0' |
> sort -z -k1,1n | tail -z -n"$nlargest" | cut -z -f2 |
> xargs -r0 ls -lUd --color=auto --
>
> Arguably that's more
Hi Berny,
On Wed, 21 Apr 2021, Bernhard Voelker wrote:
shouldn't it use the 'argv-iter' gnulib module (like du.c and wc.c)
instead of directly using the underlying ...
+#include "readtokens0.h"
I considered this, too! :)
I think the short answer is that du and wc don't actually need to
On Mon, 19 Apr 2021, Carl Edquist wrote:
I'm submitting for your consideration here a patch to add the standard
'--files0-from=FILE' option to ls.
Oops! Somehow I ended up attaching an old version of the patch - this one
includes some cleanups and help output.
Thanks,
CarlFrom
23 matches
Mail list logo
