backgrounded children forgotten
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=nocona -O3 -pipe -fomit-frame-pointer uname output: Linux vino 2.6.15-rc1 #1 SMP PREEMPT Thu Nov 17 10:10:29 EST 2005 x86_64 Intel(R) Xeon(TM) CPU 3.20GHz GenuineIntel GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: When 2 processes are backgrounded inside $(...), bash forgets the first one was a child of the shell. Repeat-By: Note this needs to be a script, not cmdline, otherwise $! doesn't work. $ cat demo output=$( true & pid=$! true & sleep 1 wait $pid ) $ bash demo demo: line 13: wait: pid 25183 is not a child of this shell ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: backgrounded children forgotten
Hi Sven, Sven Wegener wrote: [Sun Dec 11 2005, 06:56:52AM EST] > To me it looks like, that you can only wait for child processes that > are still running. The backgrounded true will exit nearly > immediately and wait can't wait for it because it has already > terminated. I agree that the child needs to have already exited to demonstrate the bug, that's why I had the sleep in there. Here is a clarification: - This version works. The exit status of the first subshell is harvested by the call to wait. $ cat demo-good #!/bin/bash ( exit 10 ) & pid=$! true & sleep 1 wait $pid echo $? >&2 $ ./demo-good 10 - This version breaks because it is inside command substitution. The exit status is lost and the error message is emitted. $ cat demo-bad #!/bin/bash output=$( ( exit 10 ) & pid=$! true & sleep 1 wait $pid echo $? >&2 ) $ ./demo-bad ./demo-bad: line 14: wait: pid 4046 is not a child of this shell 127 Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpSdINqc02XI.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: backgrounded children forgotten
Chet Ramey wrote: [Mon Dec 12 2005, 11:55:30AM EST] > I can't reproduce the problem with bash-3.1. Me neither. Sorry about that, I only tested 3.0.16 Regards, Aron -- Aron Griffis Gentoo Linux Developer ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: BUG: bash-4.0.17 and SIGWINCH during initialization
Chet Ramey wrote: [Mon Apr 13 2009, 05:48:57PM EDT] > Try the attached patch and let me know how it works. Works for me on bash-4.0.17. Thanks Chet! Aron
bash 4 patches
Hi, I noticed that patches 18-24 were released for bash-4.0 at ftp://ftp.cwru.edu/pub/bash/bash-4.0-patches/ on May 16 but I don't see any announcements in the bug-bash archive. Was this an intentional or inadvertent omission? Thanks, Aron
problem with $(
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O0 -ggdb -pipe uname output: Linux olive 2.6.11-gentoo-r4 #4 Mon May 16 10:19:39 EDT 2005 x86_64 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: Using bash internals to read /proc/net/route on amd64 stops reading at the end of the first line. Tested on bash-3.0-16 on Gentoo and Debian. Also tested on alpha, ia64 and x86, none of which exhibit the problem. Copying the pseudo-file from /proc to another location works as expected. It's only when reading directly from /proc that the problem appears. Repeat-By: $ echo "$(http://lists.gnu.org/mailman/listinfo/bug-bash
Re: problem with $(
Tatavarty Kalyan wrote: [Tue Jul 19 2005, 08:52:40AM EDT] > I was able to confirm this by running a small test program with libc > read and /proc/net/route. I did the same thing yesterday. Then I tried 2.6.13-rc3 and the problem is fixed. Seems it was a kernel issue. Aron ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
ctrl-w oddity on bash-4.4
I'm seeing some strange behavior and don't know if it's a bug or intended. Reproducer: 1. env INPUTRC=/dev/null bash --norc 2. set -o vi 3. true --foo=bar 4. up arrow, then left arrow to put the cursor on the equals sign 5. press ctrl-w, nothing happens I bisected master and found it was introduced in 4.4. Then I bisected devel and found it was introduced by http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=ccb4014f23204c5d6996dd64b5d0c824ae27469b If this is intentional then I'd be curious about the rationale. Thanks, Aron
Re: ctrl-w oddity on bash-4.4
On Sun, Oct 22, 2017 at 10:08 PM, Eduardo A. Bustamante López < dual...@gmail.com> wrote: > On Sun, Oct 22, 2017 at 06:52:12PM -0400, Aron Griffis wrote: > > I'm seeing some strange behavior and don't know if it's a bug or > intended. > [...] > > If this is intentional then I'd be curious about the rationale. > > Please read: > > http://lists.gnu.org/archive/html/help-bash/2016-11/msg4.html > > Thanks Eduardo. The clue there about bind-tty-special-chars is helpful, since previously I hadn't been able to make unix-word-rubout work either! However this doesn't seem to explain the case where ctrl-w doesn't work at all, which is the bug I'm reporting. -Aron
Re: ctrl-w oddity on bash-4.4
On Wed, Oct 25, 2017 at 9:48 AM, Chet Ramey wrote: > On 10/22/17 6:52 PM, Aron Griffis wrote: > > I'm seeing some strange behavior and don't know if it's a bug or > intended. > > > > Reproducer: > > 1. env INPUTRC=/dev/null bash --norc > > 2. set -o vi > > 3. true --foo=bar > > 4. up arrow, then left arrow to put the cursor on the equals sign > > 5. press ctrl-w, nothing happens > > Posix says the word boundaries for ^W in insert mode are characters that > aren't or . So you deal with the character before the > cursor (`o'), and delete to a character that isn't or . > Since the `o' is in neither character class, it's the word boundary, and > you don't delete anything. FWIW, ksh93 behaves the same way (but beeps > annoyingly). > Thanks Chet. Seems hard to imagine this is what a user would expect, but who am I to argue with POSIX? :-) For myself, the behavior I want is provided by the combination of bind-tty-special-chars and unix-word-rubout: set editing-mode vi # Disabling bind-tty-special-chars allows unix-word-rubout to work: # http://lists.gnu.org/archive/html/help-bash/2016-11/msg4.html set bind-tty-special-chars off set keymap vi-insert control-w: unix-word-rubout Thanks, Aron
set -e in subshell
GNU bash, version 5.0.17(1)-release (x86_64-redhat-linux-gnu) $ (set -e; false; echo BANG) || echo whimper BANG $ (set -e; false; echo BANG); echo whimper whimper The || after the subshell seems to prevent set -e from being effective inside the subshell. Is this a bug or does it make sense in a way I don't understand? Thanks, Aron
Re: set -e in subshell
On Fri, Nov 13, 2020 at 11:31 AM Chet Ramey wrote: > `set -e' doesn't have any effect on the LHS of an and-or list, and enabling > it has no effect. There have been many discussions about this. > Thanks Chet. I knew about this generally, but somehow thought subshell would be exempt. I will adjust my expectation :-) Regards, Aron
