Re: kill $! won't kill the last command in asynchronous list

On 4/1/20 12:19 AM, Oğuz wrote: > $ bash -c '{ sleep 15; } & pstree -p $!; kill $!; echo $?' > bash(6955)───sleep(6959) > 0 > $ pkill -e sleep > sleep killed (pid 6959) > > As seen above, kill $! doesn't kill `sleep` if it's enclosed in curly > braces. Dropping curly braces, or execing sleep (e.g

Re: kill $! won't kill the last command in asynchronous list

Thanks for the reply. 1 Nisan 2020 Çarşamba tarihinde Chet Ramey yazdı: > On 4/1/20 12:19 AM, Oğuz wrote: > > $ bash -c '{ sleep 15; } & pstree -p $!; kill $!; echo $?' > > bash(6955)───sleep(6959) > > 0 > > $ pkill -e sleep > > sleep killed (pid 6959) > > > > As seen above, kill $! doesn't kill

Command substitution before while loop

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-musl Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux bc55e8b47896 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 x86_64 Linux Machi

errexit and local variable set by failing command

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-musl Compiler: gcc Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security uname output: Linux bc55e8b47896 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 x86_64 Linux Machi

Re: errexit and local variable set by failing command

On Wed, Apr 01, 2020 at 04:54:42PM +, Krystian Wojtas via Bug reports for the GNU Bourne Again SHell wrote: > Script has set errexit flag. It runs function. Function declares > local variable and set it to output of run subcommand. Subcommand fails. > Script does not care and continu

Re: errexit and local variable set by failing command

Aha, already known. Thank you for link. I'll get familiar with other cases. I just figured out that it works as expected if local variable is firstly declared and then set. Pozdrawiam, Krystian Wojtas Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ środa, kwiecień 1, 2020

Re: Command substitution before while loop

On Apr 01 2020, Krystian Wojtas via Bug reports for the GNU Bourne Again SHell wrote: > Making comments in pipes using command substitution is very helpful. > But there is syntax error it it is done just before while loop. Could it be > considered as bug? Not a bug. Reserved words are

Re: Command substitution before while loop

On 4/1/20 1:47 PM, Andreas Schwab wrote: > On Apr 01 2020, Krystian Wojtas via Bug reports for the GNU Bourne Again > SHell wrote: > >> Making comments in pipes using command substitution is very helpful. >> But there is syntax error it it is done just before while loop. Could it be >>

Re: Command substitution before while loop

I see. Thank you for your answers. Best regards, Krystian Wojtas Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ środa, kwiecień 1, 2020 8:20 PM, Chet Ramey napisał(a): > On 4/1/20 1:47 PM, Andreas Schwab wrote: > > > On Apr 01 2020, Krystian Wojtas via Bug reports for the

Re: kill $! won't kill the last command in asynchronous list

On 4/1/20 12:16 PM, Oğuz wrote: > Thanks for the reply. > > 1 Nisan 2020 Çarşamba tarihinde Chet Ramey > yazdı: > > On 4/1/20 12:19 AM, Oğuz wrote: > > $ bash -c '{ sleep 15; } & pstree -p $!; kill $!; echo $?' > > bash(6955)───sleep(6959) > > 0 >

Re: errexit and local variable set by failing command

On 4/1/20 1:21 PM, Krystian Wojtas wrote: > Aha, already known. Thank you for link. I'll get familiar with other cases. > > I just figured out that it works as expected if local variable is firstly > declared and then set. That's because the exit status of a command consisting only of assignment

Re: kill $! won't kill the last command in asynchronous list

> You have to start the job with job control enabled if you want the > background process to be its own process group leader, and at that point > the shell started to run the group command will not have job control > enabled and will run all processes in the same process group (its own),' > so you

Obscure issue with process substitution since bash-5.0.016 upgrade

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

Re: Obscure issue with process substitution since bash-5.0.016 upgrade

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.