Re: Strange bash behavior

[Vladimir Marek]

Nice analysis, does the second example look similar?

bash -c 'bash -i 1; read -t 2 a < /dev/tty'

Thanks!
-- 
        Vlad

On Fri, Dec 02, 2016 at 12:59:37PM +0800, Clark Wang wrote:
> On Fri, Dec 2, 2016 at 6:28 AM, Vladimir Marek <Vladimir.Marek@oracle.com>
> wrote:
> 
> > Hi,
> >
> > I'm not sure what is going on, but the bash test suite was getting
> > stopped (as if SIGSTOP was received) in the middle. Trying to find
> > minimal set of conditions it came to this:
> >
> >  - my ~/.bashrc has to contain 'cd /' (any dir works)
> >  - the tests have to first execute run-execscript, namely it has to
> >    execute exec6.sub, namely the line ${THIS_SH} -i ./exec8.sub
> >  - the file exec8.sub is reported as not found (I presume because of the
> >    'cd /' in .bashrc)
> >  - the tests then have to run read-test, exactly in read2.sub when
> >  'read -t 2 a < /dev/tty' was executed whole thing was stopped
> >
> > When I removed the 'cd' command from my ~/.bashrc, all worked fine.
> >
> > I then tried to make minimal reproducible case and came to this (this
> > time there is no 'cd /' in my ~/.bashrc needed):
> >
> > $ bash -c 'bash -i i; bash -i i'
> > bash -c 'bash -i i; bash -i i'
> > bash: i: No such file or directory
> >
> > [1]+  Stopped                 bash -c 'bash -i i; bash -i i'
> >
> 
> I can reproduce this with bash 4.4.5 on Debian 8.5.
> 
>   foo@deb64:~$ bash -c 'bash -i 1; bash -i 2'
>   bash: 1: No such file or directory
> 
>   [1]+  Stopped                 bash -c 'bash -i 1; bash -i 2'
>   foo@deb64:~$ echo $?
>   149
> 
> It was stopped by SIGTTIN. According to gdb backtrace it was killed by the
> second "bash -i".
> 
>   4099       while ((terminal_pgrp = tcgetpgrp (shell_tty)) != -1)
>   4100         {
>   4101           if (shell_pgrp != terminal_pgrp)
>   4102             {
>   4103               SigHandler *ottin;
>   4104
>   4105               ottin = set_signal_handler (SIGTTIN, SIG_DFL);
>   4106               kill (0, SIGTTIN);
>   4107               set_signal_handler (SIGTTIN, ottin);
>   4108               continue;
>   4109             }
>   4110           break;
>   4111         }
> 
> The problem is tcgetpgrp() still returns the pgrp of the first "bash -i"
> when the second "bash -i" is running. This can be shown with following
> example:
> 
>   foo@deb64:~$ bash -c 'bash -i 1; sleep 9999'
>   bash: 1: No such file or directory    <-- CTRL-C does not work here
> 
>   root@deb64:~# ps t pts/10 j
>     PPID    PID   PGID    SID TTY       TPGID STAT   UID   TIME COMMAND
>    96886  96887  96887  96887 pts/10    97073 Ss    1001   0:00 -bash
>    96887  97072  97072  96887 pts/10    97073 S     1001   0:00 bash -c
> bash -i 1; sleep 9999
>    97072  97074  97072  96887 pts/10    97073 S     1001   0:00 sleep 9999
> 
> Here the TPGID 97073 must be the first "bash -i" which has already exited.
> Seems like for some reason the "bash -c" does not set the foreground pgrp
> to the second "bash -i".
> 
> (Still learning the APUE book. Hope my analysis makes sense. :)