On Mon, Oct 10, 2011 at 05:02:18PM -0700, jan.kolar wrote: >Christopher Faylor-8 wrote: >> On Sun, Oct 09, 2011 at 07:58:15PM -0400, Christopher Faylor wrote: >>>On Sat, Oct 08, 2011 at 05:39:20PM -0400, Ken Brown wrote: >>>>Attached is a slight modification of the STC, in which I set stdin for >>>>the bash subprocess to /dev/null. With this modification, the program >>>>works as expected (and as on Linux) with cygwin-1.7.9, but the same >>>>problem as before occurs with the latest snapshot. >>> >>>I can duplicate this problem. I'll take a look. >>> >>>Thanks for the STC. >> >> As far as I can tell, this is arguably a bug in bash. It's also an >> annoying compatibility problem between Linux and Cygwin. >> >> When the tty layer in Cygwin was first developed, the model (either in >> my head or in reality) was "If you don't have a tty and open a tty, that >> becomes your controlling tty". But, apparently that model changed over >> time to something more sensical where you have to explicitly use >> ioctl(TIOCSCTTY) to set up a controlling terminal. On Linux systems >> that would presumably be done via login(1). We don't normally run login >> on Cygwin, though. >> >> The problem is that when there is no controlling tty, bash uses a >> fallback mechanism to find the name of the tty by opening the tty >> associated with fd 0. It does this without setting the O_NOCTTY >> flag and, so, the act of opening the fd assigns a controlling >> terminal. >> >> This is not a problem on Linux (or FreeBSD for that matter) but it is a >> problem on Cygwin: it causes the aforementioned hang. So, bash could be >> modified to work around this issue but Cygwin is likely the only system >> left with this problem. So, I've modified Cygwin so that a controlling >> tty is not assigned if the fd being opened is > 2. There are still >> pathological situations which will cause problems with that but, for >> this particular problem, it seems to make bash behave better. >> >> Oh, and the reason why bash was "hanging" is because, thanks to the >> intracies of UNIX job control, it had received a SIGTSTP when an attempt >> was made to output to a tty for which bash was not the process group >> leader > >And how we can explain the hang does not happen on my machine ? >Does (older) version of bash make that difference ? > >Windows 7, cygwin-1.7.9-1 (unmodified), >GNU bash, version 3.2.49(23)-release (i686-pc-cygwin)
I'd explain it as "I don't care since you're running a different, ancient version of bash". cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
