This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gunzip 1.3.5 error reading from stdin on Cygwin [attn zsh maintainer]

Hash: SHA1

According to Bart Schaefer on 10/29/2006 10:52 AM:
> On Oct 29,  5:14am, Vin Shelton wrote:
> } Subject: Re: gunzip 1.3.5 error reading from stdin on Cygwin
> }
> } I've narrowed this down a little bit.  It only happens under zsh;
> } under bash, the recipe works without error.
> In zsh's main.c is this comment:
>  * Cygwin supports the notion of binary or text mode access to files
>  * based on the mount attributes of the filesystem.  If a file is on
>  * a binary mounted filesystem, you get exactly what's in the file, CRLF's
>  * and all.  If it's on a text mounted filesystem, Cygwin will strip out
>  * the CRs.  This presents a problem because zsh code doesn't allow for
>  * CRLF's as line terminators.  So, we must force all open files to be
>  * in text mode reguardless of the underlying filesystem attributes.

Oh no, here we go again.  This is the exact same bug that bash-3.1-6 had -
by opening ALL files in text mode from a shell, you are forced to read
those files one byte at a time to honor POSIX semantics that on a seekable
file, child processes see the same file offset as where the shell stopped
reading, but you can't reliably lseek backwards on a text mode file.  My
recommendation would be for zsh to take its turn to fix the bug and honor
binary mounts with binary semantics, even if it means that interpreting
literal \r causes strange syntax errors.

- --
Life is short - so eat dessert first!

Eric Blake   
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]