Re: wait -n shouldn't collect multiple processes
On Mär 26 2019, Ben Elliston wrote: > On Mon, Mar 25, 2019 at 04:53:02PM -0400, Chet Ramey wrote: > >> "wait waits for any job to terminate and returns its exit status" >> >> Doesn't that imply a single job? > > Not as clearly as saying "wait waits for a single job to terminate" Even better, IMHO: "wait waits for the next job to terminate" Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: wait -n shouldn't collect multiple processes
Date:Tue, 26 Mar 2019 10:55:53 +0100
From:Andreas Schwab
Message-ID:
| Even better, IMHO: "wait waits for the next job to terminate"
Something should allow for there being no waiting involved at all
if some job has already terminated but has not been waited for.
I modified Chet's script to be:
echo Running @${SECONDS}
{ sleep 1; exit 1; } &
{ sleep 5; exit 2; } &
{ sleep 5; exit 3; } &
{ sleep 5; exit 4; } &
jobs
echo Pausing @${SECONDS}
sleep 2
echo Looping @${SECONDS}
for f in 1 2 3 4; do
wait -n
echo wait return status: $? @${SECONDS}
done
echo Finishing @${SECONDS}
jobs
which results in:
jinx$ bash /tmp/AA
Running @0
[1] Running { sleep 1; exit 1; } &
[2] Running { sleep 5; exit 2; } &
[3]- Running { sleep 5; exit 3; } &
[4]+ Running { sleep 5; exit 4; } &
Pausing @0
Looping @2
wait return status: 1 @2
wait return status: 2 @5
wait return status: 3 @5
wait return status: 4 @5
Finishing @5
jinx$ bash /tmp/AA
Running @0
[1] Running { sleep 1; exit 1; } &
[2] Running { sleep 5; exit 2; } &
[3]- Running { sleep 5; exit 3; } &
[4]+ Running { sleep 5; exit 4; } &
Pausing @0
Looping @2
wait return status: 1 @2
wait return status: 4 @5
wait return status: 2 @5
wait return status: 3 @5
Finishing @5
When the first wait is done, the first job would have already
been finished for a second. "wait -n" simply collected that
one and did not pause at all. The next "wait -n" then waited
the remaining 3 seconds until there was more to collect.
This is all as it should be. The manual should reflect this.
kre
ps: those tests run with bash5, but bash4 is just the same.
Re: wait -n shouldn't collect multiple processes
On 3/26/19 8:12 AM, Robert Elz wrote: > Date:Tue, 26 Mar 2019 10:55:53 +0100 > From:Andreas Schwab > Message-ID: > > | Even better, IMHO: "wait waits for the next job to terminate" > > Something should allow for there being no waiting involved at all > if some job has already terminated but has not been waited for. Why? `wait -n' collects the exit statuses of terminated jobs one at a time. It's not really important to detail how much time is spent waiting. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Subshell exit trap is not invoked if shell exit trap also set
On 3/25/19 3:48 PM, Konstantin Andreev wrote: > Consider the simple `ssxtrap' script: > > | #!/bin/bash > | > | echo ext pid=$BASHPID > | # trap 'echo "ext exit trap in $BASHPID"' EXIT > | > | (echo int pid=$BASHPID > | trap 'echo "int exit trap in $BASHPID"' EXIT > | sleep 9) & > | > | wait > | echo "subshell done" > > Let's run it: > > Terminal A Terminal B > -- --- > | $ ./ssxtrap > | ext pid=10370 > | int pid=10371 > | $ kill 10371 > | int exit trap in 10371 > | ./ssxtrap: line 10: 10371 Terminated ... > | subshell done > > ... but if I uncomment the line that installs exit trap in the main shell, > the output changes to: > > Terminal A Terminal B > -- --- > | $ ./ssxtrap > | ext pid=10373 > | int pid=10374 > | $ kill 10374 > | ./ssxtrap: line 10: 10374 Terminated ... > | subshell done > | ext exit trap in 10373 > > i.e. subshell exit trap is not invoked anymore. > > Since subshell exit trap shall not depend from main shell exit trap, this > behaviour looks like a bug for me. I can't reproduce this using RHEL 7 or Mac OS X using bash-5.0.3. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
bash completion of an option with a space in it, isn't double quoted
From: d3fault To: bug-bash@gnu.org,b...@packages.debian.org Subject: bash completion of an option with a space in it, isn't double quoted Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR$ uname output: Linux debianD4faultHostname 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 12 Release Status: release Description: In the following example it auto-completes without putting double quotes around "hi mom", which means a process would see it as 2 separate args instead of 1. $ complete -W "hi\ mom foo bar" ls $ ls h which results in the erroneous completion (no double quotes): $ ls hi mom For a semi-related discussion which led me to discover this bug: https://bugreports.qt.io/browse/QTBUG-74692 and https://bugreports.qt.io/browse/QTBUG-74594 Repeat-By: See above. Fix: After you press tab your pending command should look like this: $ ls "hi mom"
Re: bash completion of an option with a space in it, isn't double quoted
On 3/26/19 3:43 AM, d3fault wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > Description: > In the following example it auto-completes without putting double > quotes around "hi mom", which means a process would see it as 2 > separate args instead of 1. If you want the words to be quoted, you have to say they should be quoted. If you want them quoted like filenames, tell complete they should be treated as filenames. > $ complete -W "hi\ mom foo bar" ls complete -o filenames -W "hi\ mom foo bar" ls -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Subshell exit trap is not invoked if shell exit trap also set
On Mon, Mar 25, 2019 at 6:24 PM Konstantin Andreev wrote: > Verified on: > > Solaris 11.3, bash 4.1.17(1)-release (i386-pc-solaris2.11) > CentOS Linux 7.2.1511, bash 4.2.46(1)-release (x86_64-redhat-linux-gnu) > CentOS Linux 7.2.1511, bash 5.0.0(1)-release (x86_64-pc-linux-gnu) Double check that this reproduces with bash-5. I was able to reproduce this with bash-4.2 and earlier. This does not reproduce for me with bash-4.4 and later. regards, Dmitry
Re[3]: Subshell exit trap is not invoked if shell exit trap also set
bash-5.0.3, - is it what is marked [Bash-5.0 patch 3: improve...] in bash.git? Just built and tested it. The systems are x86-64. + Debian GNU/Linux buster/sid (pre-10): works (both exit traps are invoked) (runs in virtual machine) kernel-4.18.0-3-amd64, glibc-2.28-6 - CentOS Linux 7.2.1511: NOT work (subshell exit trap is NOT invoked) (runs on real hardware) kernel-3.10.0-327.36.3.el7.x86_64, glibc-2.17 - Oracle Solaris 11.3: NOT work (subshell exit trap is NOT invoked) (runs on real hardware) system/kernel/platform 0.5.11-0.175.3.1.0.4.0 system/library 0.5.11-0.175.3.1.0.3.0 What can I do to help you isolate this issue? Best regards, Konstantin Andreev Chet Ramey, 26 Mar 2019 16:57 MSK: I can't reproduce this using RHEL 7 or Mac OS X using bash-5.0.3. Konstantin Andreev, 25 Mar 2019 22:48 MSK: Consider the simple `ssxtrap' script: | #!/bin/bash | | echo ext pid=$BASHPID | # trap 'echo "ext exit trap in $BASHPID"' EXIT | | (echo int pid=$BASHPID | trap 'echo "int exit trap in $BASHPID"' EXIT | sleep 9) & | | wait | echo "subshell done" [ ... skip ... ] ... but if I uncomment the line that installs exit trap in the main shell, the output changes to: Terminal A Terminal B -- --- | $ ./ssxtrap | ext pid=10373 | int pid=10374 | $ kill 10374 | ./ssxtrap: line 10: 10374 Terminated ... | subshell done | ext exit trap in 10373 i.e. subshell exit trap is not invoked anymore. Since subshell exit trap shall not depend from main shell exit trap, this behaviour looks like a bug for me.
Re[5]: Subshell exit trap is not invoked if shell exit trap also set
btw, I can undertake some debugging, but I have no time to investigate how the bash code works. If you may provide me with enough details so that I would know where to look into the control flow, I would investigate what's happening. Regards, Konstantin Konstantin Andreev, 26 Mar 2019 19:44 MSK: Just built and tested it. The systems are x86-64. + Debian GNU/Linux buster/sid (pre-10): works (both exit traps are invoked) - CentOS Linux 7.2.1511:NOT work (subshell exit trap is NOT invoked) - Oracle Solaris 11.3: NOT work (subshell exit trap is NOT invoked) What can I do to help you isolate this issue? Chet Ramey, 26 Mar 2019 16:57 MSK: I can't reproduce this using RHEL 7 or Mac OS X using bash-5.0.3. Konstantin Andreev, 25 Mar 2019 22:48 MSK: [ ... skip ...] Terminal A Terminal B -- --- | $ ./ssxtrap | ext pid=10373 | int pid=10374 | $ kill 10374 | ./ssxtrap: line 10: 10374 Terminated ... | subshell done | ext exit trap in 10373 i.e. subshell exit trap is not invoked anymore. Since subshell exit trap shall not depend from main shell exit trap, this behaviour looks like a bug for me.
Re: Subshell exit trap is not invoked if shell exit trap also set
On 3/26/19 12:44 PM, Konstantin Andreev wrote: > bash-5.0.3, - is it what is marked [Bash-5.0 patch 3: improve...] in bash.git? > Just built and tested it. The systems are x86-64. > > + Debian GNU/Linux buster/sid (pre-10): works (both exit traps are invoked) > (runs in virtual machine) > kernel-4.18.0-3-amd64, glibc-2.28-6 > > - CentOS Linux 7.2.1511: NOT work (subshell exit trap is NOT invoked) > (runs on real hardware) > kernel-3.10.0-327.36.3.el7.x86_64, glibc-2.17 > > - Oracle Solaris 11.3: NOT work (subshell exit trap is NOT invoked) > (runs on real hardware) > system/kernel/platform 0.5.11-0.175.3.1.0.4.0 > system/library 0.5.11-0.175.3.1.0.3.0 > > What can I do to help you isolate this issue? Run a system call tracer, I suppose. That will tell you the order in which things happen when the processes are traced, at least. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re[7]: Subshell exit trap is not invoked if shell exit trap also set
As you decide.
Debian (working), subshell syscall trace on receiving sigterm:
| $ strace -p 1436
| strace: Process 1436 attached
| wait4(-1, 0x7ffd49d66b90, 0, NULL) = ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
| --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1461, si_uid=1000} ---
| rt_sigreturn({mask=[CHLD]}) = -1 EINTR (Interrupted system call)
| rt_sigprocmask(SIG_BLOCK, NULL, [CHLD], 8) = 0
| getpid()= 1436
| write(1, "int exit trap in 1436\n", 22) = 22
| rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER,
sa_restorer=0x7f3bbdc8b940}, {sa_handler=0x5644f7bf6f40, sa_mask=[HUP INT ILL
TRAP ABRT BUS FPE USR1 SEGV USR2 PIPE ALRM TERM XCPU XFSZ VTALRM SYS],
sa_flags=SA_RESTORER, sa_restorer=0x7f3bbdc8b940}, 8) = 0
| getpid()= 1436
| kill(1436, SIGTERM) = 0
| --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1436, si_uid=1000} ---
| +++ killed by SIGTERM +++
Centos (not working):
| $ strace -p 90700
| Process 90700 attached
| wait4(-1, 0x7ffd77995430, 0, NULL) = ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
| --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=90617, si_uid=1000} ---
| +++ killed by SIGTERM +++
Regards, Konstantin.
Chet Ramey, 26 Mar 2019 21:16 MSK:
Run a system call tracer, I suppose. That will tell you the order in which
things happen when the processes are traced, at least.
Chet
Konstantin Andreev, 26 Mar 2019 19:44 MSK:
bash-5.0.3,
Just built and tested it. The systems are x86-64.
+ Debian GNU/Linux buster/sid (pre-10): works (both exit traps are invoked)
- CentOS Linux 7.2.1511:NOT work (subshell exit trap is NOT invoked)
- Oracle Solaris 11.3: NOT work (subshell exit trap is NOT invoked)
What can I do to help you isolate this issue?
Re: Re[7]: Subshell exit trap is not invoked if shell exit trap also set
Konstantin,
I also tried to replicate on CentOS (under Fusion), but get the two
expected trap messages when killing the internal process:
ext pid=25449
int pid=25450
int exit trap in 25450
subshell done
ext exit trap in 25449
Test install:
- CentOS Linux release 7.2.1511 (Core) [under VMware Fusion]
- kernel-3.10.0-327.el7.x86_64; glibc 2.17
- GNU bash, version 5.0.3(1)-release
Al
On Tue, Mar 26, 2019 at 3:24 PM Konstantin Andreev
wrote:
> As you decide.
>
> Debian (working), subshell syscall trace on receiving sigterm:
>
> | $ strace -p 1436
> | strace: Process 1436 attached
> | wait4(-1, 0x7ffd49d66b90, 0, NULL) = ? ERESTARTSYS (To be restarted
> if SA_RESTART is set)
> | --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1461,
> si_uid=1000} ---
> | rt_sigreturn({mask=[CHLD]}) = -1 EINTR (Interrupted system
> call)
> | rt_sigprocmask(SIG_BLOCK, NULL, [CHLD], 8) = 0
> | getpid()= 1436
> | write(1, "int exit trap in 1436\n", 22) = 22
> | rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=[],
> sa_flags=SA_RESTORER, sa_restorer=0x7f3bbdc8b940},
> {sa_handler=0x5644f7bf6f40, sa_mask=[HUP INT ILL TRAP ABRT BUS FPE USR1
> SEGV USR2 PIPE ALRM TERM XCPU XFSZ VTALRM SYS], sa_flags=SA_RESTORER,
> sa_restorer=0x7f3bbdc8b940}, 8) = 0
> | getpid()= 1436
> | kill(1436, SIGTERM) = 0
> | --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1436,
> si_uid=1000} ---
> | +++ killed by SIGTERM +++
>
> Centos (not working):
>
> | $ strace -p 90700
> | Process 90700 attached
> | wait4(-1, 0x7ffd77995430, 0, NULL) = ? ERESTARTSYS (To be restarted
> if SA_RESTART is set)
> | --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=90617,
> si_uid=1000} ---
> | +++ killed by SIGTERM +++
>
> Regards, Konstantin.
>
> Chet Ramey, 26 Mar 2019 21:16 MSK:
> >
> > Run a system call tracer, I suppose. That will tell you the order in
> which things happen when the processes are traced, at least.
> >
> > Chet
>
> Konstantin Andreev, 26 Mar 2019 19:44 MSK:
> >
> > bash-5.0.3,
> > Just built and tested it. The systems are x86-64.
> >
> > + Debian GNU/Linux buster/sid (pre-10): works (both exit traps are
> invoked)
> > - CentOS Linux 7.2.1511:NOT work (subshell exit trap is NOT
> invoked)
> > - Oracle Solaris 11.3: NOT work (subshell exit trap is NOT
> invoked)
> >
> > What can I do to help you isolate this issue?
>
>
