Mathieu Bonnet wrote:
> On Tuesday 08 August 2006 15:51, Chet Ramey wrote:
>>> Steps to reproduce:
>>>
>>> 4) Use "su" to login to a user (yourself, root, etc. -it does
>>> not work without using "su").
>> If it doesn't "work" without `su', it would seem to be a problem with
>> su and how it propagates signals it receives to its children.
>>
>
>
> Would it then depend on shells, terminals, and use of readline? (as
> said, with the shell "sash" compiled with readline, the problem appear,
> but not when "sash" is compiled without readline -well, I didn't check
> what the configure and makefile were doing exactly, and it seems Gentoo
> adds a patch about readline).
I took a closer look. What happens when the xterm is closed is essentially
this:
1. bash (3) gets SIGHUP, either manually or by closing the xterm
2. bash (3) sends SIGHUP to su (4) and exits
3. su (4) receives the SIGHUP, does not propagate it, and exits. This is
the key point. Had bash (5) received the SIGHUP, this would not have
been noticed. (It does not receive it because it is in a different
process group than both bash (3) and su (4), and su does not take care
to propagate signals to its children.)
4. bash (5) continues and attempts to read the next character from its
input fd. Readline gets a read error (-1/EIO), since it is now in a
different process group than the terminal, which it translates to
EOF. Since readline is documented to treat EOF on a non-empty line as
a newline, it does so, which causes the command buffer to be returned
and executed by bash as a command.
The fix is for readline to handle read errors differently from EOF, at
least when it is reading a command key sequence.
Thanks for the report and the easy-to-reproduce test case.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey, ITS, CWRU [EMAIL PROTECTED] http://cnswww.cns.cwru.edu/~chet/
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
