From:	cgf AT bbc DOT com (Christopher Faylor)
Subject:	RE: Dup2 fix
1 Mar 1998 12:44:09 -0800 :
Message-ID:	<199803012028.PAA13067.cygnus.cygwin32.developers@hardy.bbc.com>
To:	sos AT buggy DOT prospect DOT com DOT ru
Cc:	cygwin32-developers AT cygnus DOT com

Sergey wrote:
>Christopher Faylor wrote:
>> <<File: dupfix.gz>>
>> I was surprised to find zsh stopped working with the release version of
>> B19.  The reason is that it does an fdopen(..., "w+") on a file handle
>> that has been duped.
>>
>> Unfortunately, cygwin didn't preserve the settings file handles across
>> a dup.  Apparently fdopen is now checking this more stringently.
>>
>> 	patch from cgf AT bbc DOT com (Christopher Faylor)
>> 	* pipe.cc (dup2): Ensure that an fd's flags are duplicated along
>> 	with the fd itself.
>>
>
>Chris, your patch looks strange for me... hinfo_vec::dup2() copies all 
>flags! A had fdopen() problems with b19 release too, but solved them in a 
>different way:

I saw your patch, Sergey, and I applied it hoping that it would solve
my problem.  It didn't, of course, since it had nothing to do with tty
handling.

zsh does something like this:

	int fd = open("/dev/tty", O_RDWR);
	.
	.
	.
	dup2(fd, 10);
	fptty = fdopen(fd, "w+");

After zsh performs the dup2 the flags for fd 10 are 0, not 2 (O_RDWR).
So, the fdopen() fails.

I single stepped through cygwin and couldn't find any place that
duplicated the flags.  Possibly this is intended to be handled in
individual dup2 handlers but tty doesn't do it.

It makes the most sense to me that dup2 itself should do this rather
than relegating this to each specific dup2 handler since duplicating
the flags is something you want to always do when you duplicate the
file handle.
--
http://www.bbc.com/	cgf AT bbc DOT com			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."

- Raw text -