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.
_______________________________________________
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel
