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: >> <> >> 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."