Re: Assigning to BASHPID fails silently

[Martijn Dekker]

Op 20-10-16 om 14:22 schreef Greg Wooledge:
> On Wed, Oct 19, 2016 at 11:53:37PM +0200, Martijn Dekker wrote:
>> Assigning to BASHPID most certainly does have an effect. Since you
>> didn't quote that part, I think you might have missed my point that
>> attempting this will silently exit the shell without any error message,
>> causing the problem to be hard to track down.
> 
> Cannot reproduce:
> 
> imadev:~$ bash
> imadev:~$ echo $$
> 5659
> imadev:~$ BASHPID=923
> imadev:~$ echo $$
> 5659
> imadev:~$ exit
> imadev:~$ 

Urgh...

#! /usr/local/bin/bash
insubshell() {
        return "$((BASHPID=$$))"
        #                 ^ fatal typo
}
insubshell
echo continuing

The above script failed to produce output *once* (when run as 'bash
test.sh' with bash 4.4) and then output "continuing" ever since, so I
was suspecting a race condition. I can't reproduce it that way now for
the life of me, though.

However, a tweak proves I didn't lose my mind after all:

#! /usr/local/bin/bash
insubshell() {
        return "$((BASHPID=$$))"
        #                 ^ fatal typo
}
for ((i=0; i<10000; i++)); do insubshell; done
echo $i
insubshell || echo ok
echo continuing

The output of this script on my copy of bash-4.4.0 is consistently:

| 0
| continuing

Clearly, that 0 should be 10000. The 'insubshell' function somehow
manages to interrupt the 'for' loop.

So, in some contexts this bug causes a premature exit of the shell, in
others it causes a premature exit of a loop. This bug hunt could get
interesting.

This is on bash 4.4.0-release compiled by myself with default options on
Mac OS X 10.11.6 using "Apple LLVM version 7.3.0 (clang-703.0.31)",
architecture x86_64.

HTH,

- M.