Mail Archives: cygwin-apps/2002/05/23/03:00:45
On Wed, 22 May 2002, Charles Wilson wrote:
> No -- if zsh can handle cr+lf internally, then let it do so. Explicitly
> open function files in binary mode -- this will override the "textmode
> mount" which sets the default read mode.
zsh uses the open() call, not fopen(). There is no "binary" vs. "text"
mode to specify. Theoretically, open() should be opening the file in
binary mode already (ie: no text translation/interpretation), yet the
data read in clearly is being cooked under some scenarios. No, if I
understand how things are work here, I believe the carriage control
processing is being done at the filesystem level, which is below open()
and beyond my control.
But, like I said, if this causes enough trouble for people, I'll update
the code to be more relaxed on the size checking.
> That way, number of bytes reported by stat() will equal the number of
> bytes reported by read(). The buffer thus filled will contain cr+lf --
> but supposedly zsh can deal with that...
>
> --Chuck
>
>
> Matthew Smith wrote:
>
> > This sounds perfectly reasonable to me.
> >
> > cheers,
> > -Matt
> >
> >>I know of one issue concerning loading of functions. Is there another
> >>you had in mind? For the most part, zsh handles cr+lf as if it were lf
> >>implicitly. For loading functions, the code assumes a binary mode, ie:
> >>the number of bytes reported by stat() of a file is the number of bytes
> >>reported back from read() after reading in the whole file. On a
> >>filesystem mounted in textmode, this isn't always true and can cause the
> >>function to not load. I really feel this is a filesystem attribute
> >>issue, but if it's annoying enough for people, I'll loosen the size
> >>matching restrictions. A workaround for now is to strip your functions
> >>of all Carriage-Returns, thus only have linefeeds in the file.
--
Peter A. Castro <doctor AT fruitbat DOT org> or <Peter DOT Castro AT oracle DOT com>
"Cats are just autistic Dogs" -- Dr. Tony Attwood
- Raw text -