Re: Strange bash behavior
On 12/2/16 2:31 AM, Vladimir Marek wrote: > Still, this stops the bash: > > bash -c 'bash -i 1; read -t 2 a < /dev/tty' Yes, Clark found and fixed this problem. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Strange bash behavior
On 12/2/16 1:20 AM, Clark Wang wrote:
> Found the problem. The first "bash -i" changed the foreground pgrp to its
> own pgrp at startup but did not restore the original foreground pgrp when
> it exited. The following patch (not a real fix) works for me:
>
> --- a/shell.c
> +++ b/shell.c
> @@ -1504,6 +1504,7 @@ open_shell_script (script_name)
> {
>e = errno;
>file_error (filename);
> + end_job_control ();
>sh_exit ((e == ENOENT) ? EX_NOTFOUND : EX_NOINPUT);
> }
Nice catch and fix. There are a couple of other places you need to make
this change, but it's the right fix.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Strange bash behavior
> > Nice analysis, does the second example look similar? > > > > bash -c 'bash -i 1; read -t 2 a < /dev/tty' > > > > I think it's the same problem. After "bash -i" exited, "bash -c" is not the > controlling process any more so it cannot read from the tty. Ah, I see. Thanks! -- Vlad
Re: Strange bash behavior
On Fri, Dec 2, 2016 at 6:34 PM, Vladimir Marek wrote: > Nice analysis, does the second example look similar? > > bash -c 'bash -i 1; read -t 2 a < /dev/tty' > I think it's the same problem. After "bash -i" exited, "bash -c" is not the controlling process any more so it cannot read from the tty.
Re: Strange bash behavior
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
> 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 '
> bash: 1: No such file or directory<-- CTRL-C does not work here
>
> root@deb64:~# ps t pts/10 j
> PPIDPID PGIDSID TTY TPGID STAT UID TIME COMMAND
>96886 96887 96887 96887 pts/1097073 Ss1001 0:00 -bash
>96887 97072 97072 96887 pts/1097073 S 1001 0:00 bash -c
> bash -i 1; sleep
>97072 97074 97072 96887 pts/1097073 S 1001 0:00 sleep
>
> 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. :)
Re: Strange bash behavior
> > 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)
>
> Yes, though the line that runs exec8.sub is actually in execscript, and
> exec6.sub doesn't matter at all. Changing ./ to ${PWD}/ should fix it.
Probably, I thought that having 'cd' in ~/.bashrc is too exotic to make
the tests work with it. But yes, that is workaround.
Still, this stops the bash:
bash -c 'bash -i 1; read -t 2 a < /dev/tty'
> > - 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
>
> This is strange, since the presence or absence or a controlling terminal
> doesn't have anything to do with whether or not there's a cd in a startup
> script that's not run by a non-interactive shell (that is, since the read
> script isn't run by an interactive shell, your .bashrc isn't run). Very
> strange.
Sorry :)
--
Vlad
Re: Strange bash behavior
On Fri, Dec 2, 2016 at 12:59 PM, Clark Wang wrote:
> On Fri, Dec 2, 2016 at 6:28 AM, Vladimir Marek
> 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 '
> bash: 1: No such file or directory<-- CTRL-C does not work here
>
> root@deb64:~# ps t pts/10 j
> PPIDPID PGIDSID TTY TPGID STAT UID TIME COMMAND
>96886 96887 96887 96887 pts/1097073 Ss1001 0:00 -bash
>96887 97072 97072 96887 pts/1097073 S 1001 0:00 bash -c
> bash -i 1; sleep
>97072 97074 97072 96887 pts/1097073 S 1001 0:00 sleep
>
> 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".
>
Found the problem. The first "bash -i" changed the foreground pgrp to its
own pgrp at startup but did not restore the original foreground pgrp when
it exited. The following patch (not a real fix) works for me:
--- a/shell.c
+++ b/shell.c
@@ -1504,6 +1504,7 @@ open_shell_script (script_name)
{
e = errno;
file_error (filename);
+ end_job_control ();
sh_exit ((e == ENOENT) ? EX_NOTFOUND : EX_NOINPUT);
}
Re: Strange bash behavior
On Fri, Dec 2, 2016 at 6:28 AM, Vladimir Marek
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 '
bash: 1: No such file or directory<-- CTRL-C does not work here
root@deb64:~# ps t pts/10 j
PPIDPID PGIDSID TTY TPGID STAT UID TIME COMMAND
96886 96887 96887 96887 pts/1097073 Ss1001 0:00 -bash
96887 97072 97072 96887 pts/1097073 S 1001 0:00 bash -c
bash -i 1; sleep
97072 97074 97072 96887 pts/1097073 S 1001 0:00 sleep
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. :)
Re: Strange bash behavior
On 12/1/16 2:28 PM, Vladimir Marek 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)
Yes, though the line that runs exec8.sub is actually in execscript, and
exec6.sub doesn't matter at all. Changing ./ to ${PWD}/ should fix it.
> - 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
This is strange, since the presence or absence or a controlling terminal
doesn't have anything to do with whether or not there's a cd in a startup
script that's not run by a non-interactive shell (that is, since the read
script isn't run by an interactive shell, your .bashrc isn't run). Very
strange.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Strange bash behavior
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 would not go as far as thinking it's a bug, but it's very suspicious
behavior to me. Also I'm not 100% sure that both problems are identical.
I am able to reproduce on Solaris 10 and 11 and on my OpenSuse Linux.
This covers bash version 3.2.52(1), 4.1.17(1) and 4.2.53(1). I have also
reproduced on latest 4.4.5 which I was doing testing on.
At that moment I decided to seek help here :)
Thanks!
--
Vlad
