On 2/3/22 9:09 AM, Martijn Dekker wrote:
Op 02-02-22 om 20:59 schreef Chet Ramey:
[...] it makes no sense to join a process substitution to another word.
But it does. In arguments that look like assignments, and in GNU-style long
options, file names can be part of a larger word.
You're righ
On 8/6/20 12:36 PM, k...@plushkava.net wrote:
> On 06/08/2020 17:21, Eli Schwartz wrote:
>> On 8/6/20 11:31 AM, Jason A. Donenfeld wrote:
>>> That doesn't always work:
>>>
>>> set -e
>>> while read -r line; do
>>> echo "$line" &
>>> done < <(echo 1; sleep 1; echo 2; sleep 1; exit 77)
>>> sl
On 06/08/2020 17:21, Eli Schwartz wrote:
On 8/6/20 11:31 AM, Jason A. Donenfeld wrote:
That doesn't always work:
set -e
while read -r line; do
echo "$line" &
done < <(echo 1; sleep 1; echo 2; sleep 1; exit 77)
sleep 1
wait $!
echo done
I wonder why wait $! doesn't do the job here.
On 8/6/20 11:31 AM, Jason A. Donenfeld wrote:
> That doesn't always work:
>
> set -e
> while read -r line; do
>echo "$line" &
> done < <(echo 1; sleep 1; echo 2; sleep 1; exit 77)
> sleep 1
> wait $!
> echo done
So instead of your contrived case, write it properly. Check the process
subst
On 8/6/20 11:31 AM, Jason A. Donenfeld wrote:
> On Thu, Aug 6, 2020 at 4:49 PM Chet Ramey wrote:
>>
>> On 8/6/20 10:36 AM, Jason A. Donenfeld wrote:
>>> Hi Chet,
>>>
>>> On Thu, Aug 6, 2020 at 4:30 PM Chet Ramey wrote:
On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
> Hi,
>
> I
On Thu, Aug 6, 2020 at 4:49 PM Chet Ramey wrote:
>
> On 8/6/20 10:36 AM, Jason A. Donenfeld wrote:
> > Hi Chet,
> >
> > On Thu, Aug 6, 2020 at 4:30 PM Chet Ramey wrote:
> >>
> >> On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
> >>> Hi,
> >>>
> >>> It may be a surprise to some that this code here wi
On 8/6/20 10:48 AM, Chet Ramey wrote:
>> Perhaps another, clunkier, proposal would be to add `wait -s` so that
>> the wait builtin also waits for process substitutions and returns
>> their exit codes and changes $?. The downside would be that scripts
>> now need to add a "wait" after all of above
On 8/6/20 10:36 AM, Jason A. Donenfeld wrote:
> Hi Chet,
>
> On Thu, Aug 6, 2020 at 4:30 PM Chet Ramey wrote:
>>
>> On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
>>> Hi,
>>>
>>> It may be a surprise to some that this code here winds up printing
>>> "done", always:
>>>
>>> $ cat a.bash
>>> set -e -
Hi Chet,
On Thu, Aug 6, 2020 at 4:30 PM Chet Ramey wrote:
>
> On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
> > Hi,
> >
> > It may be a surprise to some that this code here winds up printing
> > "done", always:
> >
> > $ cat a.bash
> > set -e -o pipefail
> > while read -r line; do
> >echo
On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
> Hi,
>
> It may be a surprise to some that this code here winds up printing
> "done", always:
>
> $ cat a.bash
> set -e -o pipefail
> while read -r line; do
>echo "$line"
> done < <(echo 1; sleep 1; echo 2; sleep 1; false; exit 1)
> sleep 1
>
On 06/08/2020 14:57, Eli Schwartz wrote:
On 8/6/20 9:15 AM, k...@plushkava.net wrote:
You beat me to it. I was just about to suggest wait $! || exit. Indeed,
I mentioned the same in a recent bug report against wireguard-tools.
So if I understand correctly, you reported the lack of wait $! || e
On 8/6/20 9:15 AM, k...@plushkava.net wrote:
> You beat me to it. I was just about to suggest wait $! || exit. Indeed,
> I mentioned the same in a recent bug report against wireguard-tools.
So if I understand correctly, you reported the lack of wait $! || exit
in a script, and the script author in
On 06/08/2020 13:33, Eli Schwartz wrote:
On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
Hi,
It may be a surprise to some that this code here winds up printing
"done", always:
$ cat a.bash
set -e -o pipefail
while read -r line; do
echo "$line"
done < <(echo 1; sleep 1; echo 2; sleep 1; fa
6 Ağustos 2020 Perşembe tarihinde Greg Wooledge yazdı:
> On Thu, Aug 06, 2020 at 02:14:07PM +0200, Jason A. Donenfeld wrote:
> > On Thu, Aug 6, 2020 at 1:15 PM Oğuz wrote:
> > > set -e o substfail
> > > : <(sleep 10; exit 1)
> > > foo
> > >
> > > Say that `foo' is a command that take
On 8/6/20 6:05 AM, Jason A. Donenfeld wrote:
> Hi,
>
> It may be a surprise to some that this code here winds up printing
> "done", always:
>
> $ cat a.bash
> set -e -o pipefail
> while read -r line; do
>echo "$line"
> done < <(echo 1; sleep 1; echo 2; sleep 1; false; exit 1)
> sleep 1
>
On Thu, Aug 6, 2020 at 2:14 PM Jason A. Donenfeld wrote:
>
> On Thu, Aug 6, 2020 at 1:15 PM Oğuz wrote:
> >
> >
> >
> > 6 Ağustos 2020 Perşembe tarihinde Jason A. Donenfeld
> > yazdı:
> >>
> >> Hi,
> >>
> >> It may be a surprise to some that this code here winds up printing
> >> "done", always:
On Thu, Aug 06, 2020 at 02:14:07PM +0200, Jason A. Donenfeld wrote:
> On Thu, Aug 6, 2020 at 1:15 PM Oğuz wrote:
> > set -e o substfail
> > : <(sleep 10; exit 1)
> > foo
> >
> > Say that `foo' is a command that takes longer than ten seconds to complete,
> > how would you expect the sh
On Thu, Aug 6, 2020 at 1:15 PM Oğuz wrote:
>
>
>
> 6 Ağustos 2020 Perşembe tarihinde Jason A. Donenfeld yazdı:
>>
>> Hi,
>>
>> It may be a surprise to some that this code here winds up printing
>> "done", always:
>>
>> $ cat a.bash
>> set -e -o pipefail
>> while read -r line; do
>>echo "$
6 Ağustos 2020 Perşembe tarihinde Jason A. Donenfeld
yazdı:
> Hi,
>
> It may be a surprise to some that this code here winds up printing
> "done", always:
>
> $ cat a.bash
> set -e -o pipefail
> while read -r line; do
>echo "$line"
> done < <(echo 1; sleep 1; echo 2; sleep 1; false; exit
On 4/21/20 12:29 AM, Jason A. Donenfeld wrote:
> Were you planning on committing this to Savannah?
Yes, this will most likely end up as patch 17, unless a higher-priority
thing comes up first.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevi
Were you planning on committing this to Savannah?
On 4/20/20 6:02 PM, Jason A. Donenfeld wrote:
> It seems like process substitution fifo lifetime is really tricky. You
> can't really reference track, since the path is just a string that
> could be manipulated. So how do you know when it's safe to clean up
> that fd and that nobody is using it?
On Mon, Apr 20, 2020 at 3:58 PM Chet Ramey wrote:
> OK, good. It was either that or closing the fd after reaping the child
> process -- I couldn't tell 100% from the system call trace.
The latter is an interesting possibility. I assume SIGCHLD comes in
through a signal handler, so it's asynchrono
On 4/20/20 5:56 PM, Jason A. Donenfeld wrote:
> On Mon, Apr 20, 2020 at 3:49 PM Chet Ramey wrote:
>>
>> On 4/20/20 5:01 PM, Jason A. Donenfeld wrote:
>>> On 4/20/20, Chet Ramey wrote:
On 4/20/20 1:15 AM, Jason A. Donenfeld wrote:
> Hi,
>
> I've uncovered a very unusual race condi
On Mon, Apr 20, 2020 at 3:49 PM Chet Ramey wrote:
>
> On 4/20/20 5:01 PM, Jason A. Donenfeld wrote:
> > On 4/20/20, Chet Ramey wrote:
> >> On 4/20/20 1:15 AM, Jason A. Donenfeld wrote:
> >>> Hi,
> >>>
> >>> I've uncovered a very unusual race condition when using process
> >>> substitution and dev
On 4/20/20 5:01 PM, Jason A. Donenfeld wrote:
> On 4/20/20, Chet Ramey wrote:
>> On 4/20/20 1:15 AM, Jason A. Donenfeld wrote:
>>> Hi,
>>>
>>> I've uncovered a very unusual race condition when using process
>>> substitution and developed as minimal a reproducer as I could create:
>>
>> What versio
This one will reproduce immediately:
#!/bin/bash
set -e
a="my name is a"
b="my name is b"
sleep() { read -t "$1" -N 1 || true; }
doit() { sleep 0.1; "$@"; }
while true; do
doit cat <(echo "$a") <(echo "$b")
done
Here's a simpler reproducer:
set -e
a="my name is a"
b="my name is b"
pretty() { echo -e "\x1b[0m"; }
doit() { pretty; "$@"; }
while true; do
doit cat <(echo "$a") <(echo "$b")
done
On 4/20/20, Chet Ramey wrote:
> On 4/20/20 1:15 AM, Jason A. Donenfeld wrote:
>> Hi,
>>
>> I've uncovered a very unusual race condition when using process
>> substitution and developed as minimal a reproducer as I could create:
>
> What version of bash are you using?
>
5.0.016
On 4/20/20 1:15 AM, Jason A. Donenfeld wrote:
> Hi,
>
> I've uncovered a very unusual race condition when using process
> substitution and developed as minimal a reproducer as I could create:
What version of bash are you using?
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chauce
On 3/25/20 10:35 AM, Valentin Lab wrote:
> Hi,
>
> I have encountered an issue when running some bash code from 4.4 on a bash
> 5 ... I've managed to pinpoint the exact issue on my end.
Thanks for the report. This is a bug in bash-5.0, and I will have a fix in
the next devel branch push.
Chet
-
On Mon 2019-04-15 17:35:49 -0400, Chet Ramey wrote:
> I'll probably release a patch, yes. In the meantime, distributions are free
> to take the change and apply it to their versions.
Thanks for the followup! I've updated https://bugs.debian.org/920455
with the appropriate details.
--dkg
On 4/15/19 2:40 PM, Daniel Kahn Gillmor wrote:
> On Sat 2019-04-13 14:03:22 -0400, Chet Ramey wrote:
>> It's an easy change. See the attachment.
>
> Thanks! The attached patch removed a comment and changed an #if 1 to
> #if 0, but i think the comment change is just a cleanup reflecting the
> prev
On Sat 2019-04-13 14:03:22 -0400, Chet Ramey wrote:
> It's an easy change. See the attachment.
Thanks! The attached patch removed a comment and changed an #if 1 to
#if 0, but i think the comment change is just a cleanup reflecting the
previous state of the codebase. Is that right?
> I agree tha
On 4/12/19 4:28 PM, Daniel Kahn Gillmor wrote:
> None of the other bourne-derived shells that i have tried have a builtin
> wait that waits on child processes that they didn't directly create.
> It's odd that bash 5.0 does this. I don't have any objection to the
> wait builtin waiting on coproces
On Fri 2019-04-12 12:05:24 -0400, Chet Ramey wrote:
> But the execs mean that the shell that is eventually invoked to run the
> `wait' is the parent of the process substitution. So the subshell has
> children, whether or not it has run the process substitution itself.
Yes, agreed. This is the sit
On 4/11/19 6:03 PM, Daniel Kahn Gillmor wrote:
> https://bugs.debian.org/920455
It wouldn't really affect that. The reason `wait' waits for process
substitution processes is that they set $!, making them "known to the
shell" and subject to wait without arguments.
On 4/4/18 4:21 AM, Basin Ilya wrote:
> Hi.
>
> In an attempt to capture the output of 'time' I used the process substitution
> and noticed that the subshell also prints its times. Actually I this happens
> when I redirect any fd, not just stderr.
It's an interaction between command timing and t
On Wed, Apr 04, 2018 at 11:21:56AM +0300, Basin Ilya wrote:
> Hi.
>
> In an attempt to capture the output of 'time'
https://mywiki.wooledge.org/BashFAQ/032
On 3/17/17 11:30 AM, D630 wrote:
> There is a parse error in B:
Thanks for the report. I'll take a look.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.c
On 2/21/17 8:18 AM, Florian Mayer wrote:
> The following code assumes the lock to be in state not-taken before the
> snippet runs.
>
> echo foo | tee \
> >(mutex --lock; echo before; cat; echo after; mutex --unlock) \
> >(mutex --lock; echo foobar; mutex --unlock) \
> > /dev/null | ca
On Tue, Feb 21, 2017 at 03:11:22PM +0100, Florian Mayer wrote:
> >What does it do?
> It behaves like the p-operation on unary Sys-V semaphores.
OK, without digging any further into this morass, and without trying
to guess whether you've found a bug in bash or in your own tool, can I
just leave thi
On Tue, Feb 21, 2017 at 3:18 PM, Florian Mayer wrote:
> The following code assumes the lock to be in state not-taken before the
> snippet runs.
>
> echo foo | tee \
> >(mutex --lock; echo before; cat; echo after; mutex --unlock) \
> >(mutex --lock; echo foobar; mutex --unlock) \
> >
What does it do?
It behaves like the p-operation on unary Sys-V semaphores. If the semaphore has
not been taken (has had the value 1), mutex --lock immediately exits. If the
semaphore has indeed been taken already (has the value 0), mutex --lock will
try to gain the lock and only exit if it wa
On Tue, Feb 21, 2017 at 4:00 PM, Pierre Gaston
wrote:
>
>
> On Tue, Feb 21, 2017 at 3:18 PM, Florian Mayer
> wrote:
>
>> The following code assumes the lock to be in state not-taken before the
>> snippet runs.
>>
>> echo foo | tee \
>> >(mutex --lock; echo before; cat; echo after; mutex --u
On Tue, Feb 21, 2017 at 02:18:03PM +0100, Florian Mayer wrote:
> for mutex --lock I use a tool which I wrote myself.
What does it do?
> The following code assumes the lock to be in state not-taken before the
> snippet runs.
What lock?
> echo foo | tee \
> >(mutex --lock; echo before; cat;
The following code assumes the lock to be in state not-taken before the
snippet runs.
echo foo | tee \
>(mutex --lock; echo before; cat; echo after; mutex --unlock) \
>(mutex --lock; echo foobar; mutex --unlock) \
> /dev/null | cat
for mutex --lock I use a tool which I wrote myself
On Mon, Feb 20, 2017 at 11:25:22PM +0100, Florian Mayer wrote:
> echo foo | tee >(echo $$) >(echo $$) >/dev/null | cat
>
> returns the same PID twice.
$$ is the PID of the main shell. I think what you want is the PID of
each subshell, $BASHPID.
imadev:~$ cat <(echo $$) <(echo $$)
3751
3751
imad
On 2/16/17 3:36 PM, David Simmons wrote:
> [ Re-sending... it doesn't look like this went through the first time. ]
>
> Bash uses 0x01 (CTLESC) and 0x7F (CTLNUL) bytes within command word strings
> that are passed around internally. If either of these bytes appear in the
> parser input, they are
On Fri, Feb 13, 2015 at 05:10:42PM +, Pádraig Brady wrote:
> bash though seems to connect the stdout of the process substitution
> to the pipeline, which seems like a bug:
> $ : | tee >(md5sum) | sha1sum
> 253a7a49edee354f35b2e416554127cf29c85724 -
md5sum inherits the anonymous pipe to sha1su
On 11/6/12 7:09 AM, Zev Weiss wrote:
> Bash Version: 4.2
> Patch Level: 39
> Release Status: release
>
> Description:
>
> It seems that when bash passes (the expanded form of) a
> process substitution to a function and that function then uses
> the argument in a pipeline, the f
On 8/7/11 7:02 PM, Curtis Doty wrote:
> On Sun, 7 Aug 2011, Chet Ramey wrote:
>
>> On 8/7/11 6:00 PM, Curtis Doty wrote:
>>> local job jobcount=0
>>> while read job
>>> do ((jobcount++))
>>> done < <(jobs)
>>
>> As you suspect, the problem is with this part of the function. It doesn't
>>
On Sun, 7 Aug 2011, Chet Ramey wrote:
On 8/7/11 6:00 PM, Curtis Doty wrote:
local job jobcount=0
while read job
do ((jobcount++))
done < <(jobs)
As you suspect, the problem is with this part of the function. It doesn't
really have anything to do with PROMPT_COMMAND, though. You must
On 8/7/11 6:00 PM, Curtis Doty wrote:
> I've recently refactored my PROMPT_COMMAND function to avoid superfluous
> fork()s. In the body of the function, what was once this line:
>
> local jobcount=$(jobs |wc -l)
>
> is now this:
>
> local job jobcount=0
> while read job
> do ((jobcount++
On 8/2/11 10:08 AM, Maarten Billemont wrote:
> In the following snippet, I expect the two ls' to give the same output.
> However, it appears the process substitution's temporary file sometimes
> vanishes for the second. Can someone explain why and whether this is the
> desired behavior or not?
> Bash Version: 4.1
> Patch Level: 5
> Release Status: release
>
> Description:
> Error codes from process substitution subshells go undetected,
> even with current most-paranoid flags set. I propose "set -o
> procsubfail" to fix this, though I'm unsure what changes to the
> codebase this
On Tue, Jun 08, 2010 at 12:53:47PM -0500, Peng Yu wrote:
> I have a program that only accept argument with a give suffix
>
> ./program xxx.suffix
>
> If I use process substitution, which gives me /dev/fd/xx, it will not
> work with the program. Is there a way to make sure a suffix is added
> to t
On 2/11/10 6:04 AM, Ian wrote:
> Basically, by mixing IO redirection and process substitution I'm left
> with a trailing file descriptor which can cause scripts to hang around
> despite any subsequent redirection of stdout/stderr best practices.
> There's no mechanism to discover these new file d
On 11 Feb, 20:29, Greg Wooledge wrote:
> When the shortcuts are too short, you need to fall back to the original
> tools. In this case, >() is really just a shortcut for "create a FIFO,
> and open it". Doing so by hand should give you the manual control you
> need. At the very least, you can te
Ian wrote:
> The manual suggests I could move and close file descriptors with
>
> [n]>&digit-
>
> but I would need the equivalent of
>
> command1 >&>(...)-
>
> Digit might very well mean (just a) digit but here the process
> substitution, of course, is replaced with /dev/fd/63, say, certai
On Thu, Feb 11, 2010 at 03:04:30AM -0800, Ian wrote:
> The manual suggests I could move and close file descriptors with
>
> [n]>&digit-
>
> but I would need the equivalent of
>
> command1 >&>(...)-
>
> Digit might very well mean (just a) digit but here the process
> substitution, of course
Marc Herbert wrote:
>> On Mon, Oct 12, 2009 at 1:14 PM, Ralf Goertz
>>> is it possible to have a process substitution with both input and
>>> output redirection? So far I use the following work-around
>>>
cat parentprocess.sh:
>>> #!/bin/bash
>>> mkfifo fifo 2>/dev/null
>>> exec 5> >(./subpro
> On Mon, Oct 12, 2009 at 1:14 PM, Ralf Goertz
>> is it possible to have a process substitution with both input and output
>> redirection? So far I use the following work-around
>>
>>> cat parentprocess.sh:
>> #!/bin/bash
>> mkfifo fifo 2>/dev/null
>> exec 5> >(./subprocess.sh > fifo)
>> exec 6< <(
On Mon, Oct 12, 2009 at 1:14 PM, Ralf Goertz
wrote:
> Hi,
>
> is it possible to have a process substitution with both input and output
> redirection? So far I use the following work-around
>
> > cat parentprocess.sh:
> #!/bin/bash
> mkfifo fifo 2>/dev/null
> exec 5> >(./subprocess.sh > fifo)
> exe
Bob Proulx wrote:
> Chet Ramey wrote:
>> No, there's no way to wait for it.
>
> Hmm... That does make it very difficult to actually use correctly.
Not really, if you think about the intended use. The original intent
was to allow applications to read and write to and from processes
in cases wher
Chet Ramey wrote:
> No, there's no way to wait for it.
Hmm... That does make it very difficult to actually use correctly.
If there are any practical uses I am missing seeing them. Any useful
examples? Is that enough of a misfeature to qualify as a bug?
Bob
Bob Proulx wrote:
> I am confused by the order of operations of this following:
>
> $ { echo hello world | tee >(md5sum 1>&2) ;} ; echo goodbye
> hello world
> goodbye
> $ 6f5902ac237024bdd0c176cb93063dc4 -
>
> Shouldn't bash wait for the subprocess finish before the next command
> is in
> Machine Type: i386-portbld-freebsd5.3
>
> Bash Version: 3.0
> Patch Level: 16
> Release Status: release
>
> Description:
> Process substitution doesn't work on FreeBSD 5.3 due to corruption of
> the data. I've tested on other versions of FreeBSD (4.x) and Linux and there
> are no proble
68 matches
Mail list logo
