Makeing the subshell reliable

Pavel Tsekov ptsekov at gmx.net
Fri Jul 21 14:27:47 UTC 2006


On Thu, 20 Jul 2006, Oswald Buddenhagen wrote:

> actually matter. sigchld from the shell means it's ready. then we should
> - purge it's input if we were in panel mode, so it does not start with
>  the next command under us. we do this. you are suggesting that this
>  can't work - why?

This is what the code was supposed to do already. I trusted the code
since it was working fine on Linux - this led me to believe that
something (the pty implementation) was playing tricks and flush requests
were coming too late - after the input was swallowed. Your question made 
me think again... The first thing which seemd suspicious was the code 
that flushed the input:

[...]
/* Discard all remaining data from stdin to the subshell */
tcflush (subshell_pty, TCOFLUSH);
[...]

It is supposed to flush the input, right ? Why flushing the output
then ? I logged to the FreeBSD machine and changed TCOFLUSH to TCIFLUSH
and it worked! Next, I logged in to my Solaris machine - changing the
argument to tcflush() didn't help. I checked the return value of tcflush()
and it was -1 with errno set to EINVAL. The Solaris man page has some 
interesting info on the matter:

[...]
      The standard set of termio ioctls are supported by the slave
      device.
[...]

Seems logical. After all the slave is emulating the tty interface.
Ok. I modified the code to flush the input channel (TCIFLUSH) on the slave 
side of the pty (subshell_pty is the master) and it worked on Linux, 
FreeBSD and Solaris!

I'll apply a fix soon.

Oswald, once again I have to thank you! As always your opinion is much 
appreciated!

P.S. Even though a solution has been found for this problem I still think
the code which reads the prompt should go. Other improvements as discussed
in this threads should be also considered. In fact I plan to review the
signal handling of SIGCHLD.



More information about the mc-devel mailing list