On Wed, Feb 19, 2025, at 9:48 PM, Dale R. Worley wrote:
> What it is really doing is "declare foo to
> be the history file, and then read its contents and put them in the
> history list". The problem as I see it is that the easiest to spot part
> of the documentation is
>
> -r Re
Andreas Schwab writes:
> On Feb 14 2025, Dale R. Worley wrote:
>
>> And really, that means that the effect of -r is kind of complicated and
>> unintuitive.
>
> Not really. The command uses either the supplied filename or $HISTFILE
> to name the file to operate on. Other than that, the filename a
On 2/14/25 9:48 AM, Chet Ramey wrote:
I think it's reasonable for the history builtin to report read errors here,
something like this:
bash: history: /dev/fd/63: read error: Inappropriate file type or format
The problem with this is that it errors on /dev/null, which has always
worked and is
On Feb 14 2025, Dale R. Worley wrote:
> And really, that means that the effect of -r is kind of complicated and
> unintuitive.
Not really. The command uses either the supplied filename or $HISTFILE
to name the file to operate on. Other than that, the filename argument
has no effect.
--
Andrea
Chet Ramey writes:
> It fails because the history library requires the file to be a regular
> file. It tries to read and write atomically, so the read history function
> gets the size of the history file, allocates one big buffer to hold it,
> and reads it in one go.
Though in regard to the comma
On 2/14/25 5:31 AM, MacBeth wrote:
Ummm, isn't this supposed to work? I'm guessing there's a technical
reason why it doesn't...?
# fails:
$ history -r <(echo 'echo bad')
It fails because the history library requires the file to be a regular
file. It tries to read and write atomically, so the r
is that if fifo or if nonormal file ..
.. is that another story from history .. ?
that it doesnt accept them ..
On Fri, Feb 14, 2025, 1:36 PM Greg Wooledge wrote:
> On Fri, Feb 14, 2025 at 05:19:48 -0600, MacBeth wrote:
> > On Fri, Feb 14, 2025 at 4:31 AM MacBeth
> wrote:
> > > # fails:
> > > $
On Fri, Feb 14, 2025 at 05:19:48 -0600, MacBeth wrote:
> On Fri, Feb 14, 2025 at 4:31 AM MacBeth wrote:
> > # fails:
> > $ history -r <(echo 'echo bad')
>
> Unless the reason is due to the file seek issue as described here...?
> https://unix.stackexchange.com/a/164109
hobbit:~$ echo ': testing f
it looks me cause such as it isnt a file , yes ..
On Fri, Feb 14, 2025, 12:20 PM MacBeth wrote:
> On Fri, Feb 14, 2025 at 4:31 AM MacBeth wrote:
> >
> > Ummm, isn't this supposed to work? I'm guessing there's a technical
> > reason why it doesn't...?
> >
> > # fails:
> > $ history -r <(echo 'ec
On Fri, Feb 14, 2025 at 4:31 AM MacBeth wrote:
>
> Ummm, isn't this supposed to work? I'm guessing there's a technical
> reason why it doesn't...?
>
> # fails:
> $ history -r <(echo 'echo bad')
>
Unless the reason is due to the file seek issue as described here...?
https://unix.stackexchange.com/
Ummm, isn't this supposed to work? I'm guessing there's a technical
reason why it doesn't...?
# fails:
$ history -r <(echo 'echo bad')
# succeeds:
$ history -w >(cat -n)
-
$ help | head -n 1
GNU bash, version 5.2.37(1)-release (aarch64-apple-darwin23.4.0)
$ echo 'echo good' > hist.txt
$ cat
On 11/17/24 6:25 PM, Robert Elz wrote:
The use for testing for errors is also occasionally useful - a redirection
error will cause the shell to exit (non-interactive shell) so &2 message; exit 2; }
(or similar) (and output directions test that the file either exists or
can be created, and is wri
On 11/17/24 1:16 PM, Mike Peters wrote:
On 2024-11-16 22:56, Lawrence Velázquez wrote:
On Sat, Nov 16, 2024, at 9:35 PM, Greg Wooledge wrote:
On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
Description:
Process substitution does not generate properly when pulling
from
Date:Sun, 17 Nov 2024 12:16:40 -0600
From:Mike Peters
Message-ID:
| * (Although I have yet to determine any purpose or significance of
| these redirections in the manual, other than simply not causing an error,
| as it "do[es] not affect the current shell envi
onsistent and logically valid with the manual... Process substitution
> 'takes the form of <(list) or >(list)'. The grammar defines 'list' to
> be 'a sequence of one or more pipes', a 'pipeline' to be 'a sequence of
> one or more comman
On Sun, Nov 17, 2024 at 12:16:29 -0600, Mike Peters wrote:
> On 2024-11-16 20:35, Greg Wooledge wrote:
> > On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
> > > > exec 3 > > > cat <&3
> > > foobar
> >
> > OK. This part is straightforward. Note that you used
On 2024-11-16 22:56, Lawrence Velázquez wrote:
On Sat, Nov 16, 2024, at 9:35 PM, Greg Wooledge wrote:
On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
Description:
Process substitution does not generate properly when pulling from another file
descriptor, although it works
On 2024-11-16 20:35, Greg Wooledge wrote:
On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
Description:
Process substitution does not generate properly when pulling from another file
descriptor, although it works when pulling from a file directly. In the below sample shell
On Sat, Nov 16, 2024, at 9:35 PM, Greg Wooledge wrote:
> On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
>> Description:
>> Process substitution does not generate properly when pulling from
>> another file descriptor, although it works when pulling from a
On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
> Description:
> Process substitution does not generate properly when pulling from
> another file descriptor, although it works when pulling from a file directly.
> In the below sample shell session, it is expected
3.3.0 Darwin Kernel Version 23.3.0:
Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.$
Machine Type: aarch64-apple-darwin23.4.0
Bash Version: 5.2
Patch Level: 37
Release Status: release
Description:
Process substitution does not generate properly when pulling from another file
descriptor, alt
h _pattern_ undergoes tilde expansion, parameter
expansion, command substitution, arithmetic expansion,
process substitution, and quote removal.
I'm confused. Why is "process substitution" being performed here?
It's performed because it&#
, parameter
expansion, command substitution, arithmetic expansion,
process substitution, and quote removal.
I'm confused. Why is "process substitution" being performed here?
The result is often unforeseen, e.g., '/dev/fd/13', '/dev/fd/42&#
,
command substitution, process substitution, and quote removal
on those words (the expansions that would occur if the words
were enclosed in double quotes).
However, the parenthetical is misleading because tilde expansion
and process substitution don't occur within d
Both the manual [1] and man page [2] state:
The words between the [[ and ]] do not undergo word splitting
and filename expansion. The shell performs tilde expansion,
parameter and variable expansion, arithmetic expansion,
command substitution, process substitution
On 2/2/24 3:32 PM, Tavian Barnes wrote:
Bash Version: 5.2
Patch Level: 26
Release Status: release
Description:
When a SIGCHLD trap is set, commands that include two process
substitutions fail with a strange "unexpected EOF" error.
Thanks for the report. This was fixed last September, the re
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wfo
rmat -Werror=format-security -fstack-clash-protection
-fcf-pr
does not make zsh "correct".
It all depends upon the definition of what is supposed to happen
to the stdout of a process created as a process substitution
which is to read from its stdin (as in the example in question)
or what it should do with its stdin if intended to write output
through
On Nov 18 2023, Daniel Barrett via Bug reports for the GNU Bourne Again SHell
wrote:
> If it's helpful, here's another interesting piece of the puzzle: the
> "xsel -i" command (which also copies stdin to the X primary selection,
> like "xclip -i" does) works fine in the original pipeline, without
he WM tells it that its selection is no
longer required, and that's the delay that you're seeing.
On Sat, 18 Nov 2023 at 23:36, dbarrett--- via Bug reports for the GNU
Bourne Again SHell wrote:
> The following command, when run in bash, should copy the word "foo" to
> the X pr
On November 18, 2023, Greg Wooledge wrote:
>On Sat, Nov 18, 2023 at 08:36:06AM -0500, dbarrett--- via Bug reports for the
>GNU Bourne Again SHell wrote:
>> echo foo | tee >(xclip -i) | tr o x
>>
>> The command does print "fxx" but then it hangs.
>>
>> The same command behaves correctly when run
On Nov 18 2023, Greg Wooledge wrote:
> On Sat, Nov 18, 2023 at 08:36:06AM -0500, dbarrett--- via Bug reports for the
> GNU Bourne Again SHell wrote:
>> echo foo | tee >(xclip -i) | tr o x
>>
>> The command does print "fxx" but then it hangs.
>>
>> The same command behaves correctly when run in
On Sat, Nov 18, 2023 at 08:36:06AM -0500, dbarrett--- via Bug reports for the
GNU Bourne Again SHell wrote:
> echo foo | tee >(xclip -i) | tr o x
>
> The command does print "fxx" but then it hangs.
>
> The same command behaves correctly when run in zsh.
For the record, here's what processes are
Bash Version: 5.2
Patch Level: 21
Release Status: release
Description:
The following command, when run in bash, should copy the word "foo" to
the X primary selection (by process substitution), output the line
"fxx", and exit:
echo foo | tee >(xclip -i) | tr o x
The comma
On 10/31/22 1:31 AM, Hyunho Cho wrote:
# this is an error
# [[ ]] command recognizes ">(.*)" as process substitution.
bash$ [[ $val =~ ((.*)<[^>]*>(.*)) ]] && echo yes # Error !
bash$ .*: command not found
Yes, process substitution is one of the word expansi
On 10/28/22 6:37 AM, ad...@nosuck.org wrote:
Thank you for the awesome shell. I noticed the following after upgrading
from 5.1.16-3 to 5.2.2-2 on Fedora. It actually resulted in a minor amount
of data loss.
Thanks for the report. I believe this was fixed a couple of weeks ago as
the result o
regex string ">(...)" in [[ ]] command is recognized as
process substitution
when using "( )" parentheses.
# this all works fine #
val="delete unset"
bash$ regex='(.*) <[^>]*> (.*)'
bash$ [[ $val =~ $regex ]] && ech
On Fri, 28 Oct 2022 at 20:37, wrote:
> Thank you for the awesome shell. I noticed the following after upgrading
> from 5.1.16-3 to 5.2.2-2 on Fedora. It actually resulted in a minor
> amount
> of data loss.
After fixing the attached file to remove the carriage returns, I was able
to reproduce
Thank you for the awesome shell. I noticed the following after upgrading
from 5.1.16-3 to 5.2.2-2 on Fedora. It actually resulted in a minor amount
of data loss.
#!/usr/bin/env -S bash --
mapfile -t < <(
cat <<- EOF
;FFMETADATA1
EOF
while read -r ; do
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&#x
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.
Assuming tar is GNU tar, something like
tar -c
On Jul 11 2021, Greg Wooledge wrote:
> You're sending the stderr of generate to a subshell where the stderr()
> function is executed. But the stderr() function writes to stdout.
> Therefore, all of the output from generate is ultimately ending up going
> to the script's stdout, with potentially w
On Sun, Jul 11, 2021 at 11:09:10AM +0100, earnestly wrote:
> What appears to be happening is that the output from standard error is
> being mixed into the function handling standard out, even more
> surprisingly that xtrace output is also being consumed and filtered as
> well.
First, xtrace (set -
(x86_64-pc-linux-gnu)
>
> I have attempted to use process substitution in order to feed the
> output of a command into two filters, one for handling stdout and the
> other for stderr.
>
> Prior to this I was using POSIX sh and named pipes to achieve this but
> decided
GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu)
I have attempted to use process substitution in order to feed the
output of a command into two filters, one for handling stdout and the
other for stderr.
Prior to this I was using POSIX sh and named pipes to achieve this but
decided to try
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
! doesn't do the job here.
So instead of your contrived case, write it properly. Check the process
substitution first, and make sure as a bonus you don't run anything if
if it failed:
set -e
mapfile -t lines < <(echo 1; sleep 1; echo 2; sleep 1; exit 77)
wait $!
for line in "$
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
;>>> 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
>>>>> echo done
>>>>>
>>>>&g
echo "$line"
> >>> done < <(echo 1; sleep 1; echo 2; sleep 1; false; exit 1)
> >>> sleep 1
> >>> echo done
> >>>
> >>> $ bash a.bash
> >>> 1
> >>> 2
> >>> done
> >>>
> >>> T
quot;wait" after all of above such loops, but on the
>> upside, it's better than the current problematic situation.
>
> You can already do this. Since process substitution sets $!, you can
> keep track of all of the process substitutions of interest and wait
> for as ma
;>> "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
>>>
-e -o pipefail
> > while read -r line; do
> >echo "$line"
> > done < <(echo 1; sleep 1; echo 2; sleep 1; false; exit 1)
> > sleep 1
> > echo done
> >
> > $ bash a.bash
> > 1
> > 2
> > done
> >
> > T
ho 1; sleep 1; echo 2; sleep 1; false; exit 1)
> sleep 1
> echo done
>
> $ bash a.bash
> 1
> 2
> done
>
> The reason for this is that process substitution right now does not
> propagate errors. It's sort of possible to almost make this better
> with `||
o be, with wait $! being one way of
doing so. That being said, the proposed solution eschewed the use of
process substitution altogether.
I concur. The scripts I looked at tended heavily towards error handling
at a distance and were already subject to one or two amusing errexit
pitfalls.
lol
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
; sleep 1; echo 2; sleep 1; false; exit 1)
sleep 1
echo done
$ bash a.bash
1
2
done
The reason for this is that process substitution right now does not
propagate errors.
Well, yes, it is an async command. But errexit has lots of other amusing
traps, like
$ echo $(false)
It's sort of poss
> >
> > > Say that `foo' is a command that takes longer than ten seconds to
> complete, how would you expect the shell to behave here? Should it
> interrupt `foo' or wait for its termination and exit then? Or do something
> else?
> >
> > It's likely
ho 1; sleep 1; echo 2; sleep 1; false; exit 1)
> sleep 1
> echo done
>
> $ bash a.bash
> 1
> 2
> done
>
> The reason for this is that process substitution right now does not
> propagate errors.
Well, yes, it is an async command. But errexit has lots of other amusing
t
rprise 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
o complete,
> > how would you expect the shell to behave here? Should it interrupt `foo' or
> > wait for its termination and exit then? Or do something else?
>
> It's likely simpler to check after foo, since bash can just ask "are
> any of the process substitut
h
>> 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
>> echo done
>>
>> $ bash a.bash
>> 1
>> 2
>> done
>>
>> The
< <(echo 1; sleep 1; echo 2; sleep 1; false; exit 1)
> sleep 1
> echo done
>
> $ bash a.bash
> 1
> 2
> done
>
> The reason for this is that process substitution right now does not
> propagate errors. It's sort of possible to almost make this better
> w
he reason for this is that process substitution right now does not
propagate errors. It's sort of possible to almost make this better
with `|| kill $$` or some variant, and trap handlers, but that's very
clunky and fraught with its own problems.
Therefore, I propose a `set -o substfail` opt
> >
> > shopt -s extdebug
> > trap : DEBUG
> > : < <(:)
>
> Thanks for the report. I can't reproduce this with macOS, but I can with
> RHEL 7. I'll take a look.
>
Thanks!
The EOF hunch made me decide to see what happened with ignoreeof set. Sure
en
On 8/3/20 9:44 PM, Jonathan Rascher wrote:
> $ bash --version
> GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
>
> $ uname -a
> Linux penguin 5.4.40-04224-g891a6cce2d44 #1 SMP PREEMPT Tue Jun 23 20:21:29
> PDT 2020 x86_64 GNU/Linux
>
> (This is a Pixelbook running the default Crostini L
$ bash --version
GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)
$ uname -a
Linux penguin 5.4.40-04224-g891a6cce2d44 #1 SMP PREEMPT Tue Jun 23 20:21:29
PDT 2020 x86_64 GNU/Linux
(This is a Pixelbook running the default Crostini Linux VM under Chrome
OS 84.0.4147.110. I can reproduce the
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 t
forward to the release of 5.0.017.
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? I suppose you h
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?
>>>>
>>&
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 un
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
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
Hi,
I've uncovered a very unusual race condition when using process
substitution and developed as minimal a reproducer as I could create:
set -e
private="$(wg genkey)"
public="$(wg genkey | wg pubkey)"
preshared="$(wg genpsk)"
ip link del wg0 type wireguard ||
Thanks for your attention and the provided reduced patch. I can
confirm that, applied over bash-5.0.16, this solves my issue, both on
the test case as well as the bigger application from which it was
extracted.
Regards,
- Joan Bruguera
On Thu, 2 Apr 2020 at 23:20, Chet Ramey wrote:
>
> On 4/1/20
On 4/1/20 10:15 PM, Joan Bruguera Micó wrote:
> I'm having a problem with a script that used to work, which I reduced
> to the following test case:
>
> #!/bin/bash
>
> function docat() {
> for x in 1 2 3 ; do true; done
> cat "$@"
> }
>
> for x in $(seq 25); do
>
Apologies, since after reading the other bug report more thoroughly, I
understood that a fix for that issue has actually already been commited to
the devel branch at this point, and indeed, I can also not reproduce my
issue on the latest snapshot. So it looks like this has already been
addressed.
I'm having a problem with a script that used to work, which I reduced
to the following test case:
#!/bin/bash
function docat() {
for x in 1 2 3 ; do true; done
cat "$@"
}
for x in $(seq 25); do
docat <(echo a) <(echo a) <(echo a) <(echo a) <(echo a) <(echo
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
-
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.
Here are 2 functions that are quite similar, except the usage of "{ ; }"
around the "cat":
##
ouch() {
cat < <(echo bar)
cat "$1"
On 12/8/19 4:29 AM, Oğuz wrote:
I think otherwise. In POSIX mode Bash should at least print warnings
about features POSIX lets implementations provide but doesn't mandate,
like function, select, [[, etc.
This is not, and never has been, the purpose of bash's POSIX mode. If you
want this, there
Op 08-12-19 om 10:29 schreef Oğuz:
I think otherwise. In POSIX mode Bash should at least print warnings
about features POSIX lets implementations provide but doesn't mandate,
like function, select, [[, etc.
That would be a far bigger change than just allowing process substitution.
Also,
I think otherwise. In POSIX mode Bash should at least print warnings
about features POSIX lets implementations provide but doesn't mandate,
like function, select, [[, etc.
--
Oğuz
Process substitution is disabled in POSIX mode. A 'git blame' on parse.y
suggests that this has been the case since bash prehistory.
To me, this seems:
- Inconsistent. Other bash extensions are not disabled when POSIX mode
is active; as far as I can tell, this is the only one.
- U
On 9/21/19 7:21 PM, Grisha Levit wrote:
> Running the below a few times results in a stray child bash process
> (and a borked terminal, as the child will still read from the same
> tty):
>
> kill -INT -$$ & while :; do : <(:); done
>
> This seems to have started with bash-20150724 [1] and is
Running the below a few times results in a stray child bash process
(and a borked terminal, as the child will still read from the same
tty):
kill -INT -$$ & while :; do : <(:); done
This seems to have started with bash-20150724 [1] and is present in
the current devel branch.
[1]
https://git
On 7/31/19 2:35 PM, Travis Everett wrote:
> Bash Version: 5.0
> Patch Level: 7
> Release Status: release
>
> Description:
>I stumbled into an odd interaction between process substitution and
> a SIGCHLD trap that causes syntax errors in otherwise valid commands.
>
~2/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin17.7.0
Bash Version: 5.0
Patch Level: 7
Release Status: release
Description:
I stumbled into an odd interaction between process substitution and
a SIGCHLD trap that causes syntax errors in otherwise valid commands.
I managed
On 6/21/19 2:58 PM, k...@plushkava.net wrote:
> However, merely by assigning a variable prior to the loop, though within the
> same line, the number will continuously grow:
>
> $ var=0; while :; do { read; } < <(:); sleep 0.5; printf %s\\n
> /proc/self/fd/* | wc -l; done
> 6
> 7
> 8
> 9
> 10
>
Hi,
As tested interactively with bash 5.0.7(1) and GNU/Linux, the following command
prints a constant number of active file descriptors, as expected:
$ while :; do { read; } < <(:); sleep 0.5; printf %s\\n /proc/self/fd/* | wc
-l; done
6
6
6
6
6
... etc
However, merely by assigning a variable
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
1 - 100 of 247 matches
Mail list logo
