Mail Archives: cygwin/2010/04/21/05:04:41
2010/04/21 2:12 Peter A. Castro wrote:
> Greetings, Yutaka,
Greetings, Peter. Thank you for your reply.
> The text-mode "hack" was created to solve a basic problem that zsh has
> with running scripts, in general, on Windows. Much of the code assumes
> that scripts have a single-character line terminator (eg: LF). So do
> many text-based programs and filters. Windows "native" line termination
> is (still) CRLF and zsh code does not deal well with this.
>
> Cygwin's text-mode munches the CR from the stream input leaving the LF
> which works well in 99% of the usage cases. Without it, Zsh treats the
> CR as part of the input line and tries to parse it as such leading to
> "Bad Things"(tm) happening. The same think would be true of data read
> via the shell and passed to other programs as stdin. There's also some
> size calculations that only work with a single-character line terminator
> (at least in zsh code).
Could you give me a simple test case that fails without
cygwin_premain0()? I set my filesystems as text-mode and tried to find
such cases, but I couldn't.
I thought about two cases:
* If you don't use CRLF scripts at all and mount all your filesystems as
binary-mode, there should be no problem (without premain hack).
* If you use CRLF scripts and mount all your filesystem as text-mode,
there should be no problem (without premain hack).
Is it right?
> A while back I looked at making changes to somehow acommodate CRLF, but
> there are many places in the code that would require some heavy changes
> (some of which I'm still not certain would be correct) and would make it
> difficult to maintain. I doubt that Zsh base would accept such changes
> either as they would be an intrusive hack for Windows only support. By
> contrast the premain hack was elegent and global.
>
> I could have simply told people that they had to run scripts from a
> non-text-mode mount, that their /tmp had to also be on a non-text-mode
> mount and all data the scripts explicitly read from were also on a
> non-text-mode mount AND all scripts (and input data) must be non-CRLF.
> Think that would fly? Me neither. That was the basis for this "fix" in
> the first place.
I don't know well about zsh code, but I think it will be hard to do the
hack without cygwin_premain0(), as you said. But, how about bash? bash
seems not to have such hacks, but it seems to work well. And I think
it's confusing that bash and zsh treat stdin as different mode.
> And how is base64's deficiency a zsh problem? Stdin/Stdout are "text"
> handles, which implies possible data manipulation along those lines.
> There's no guarantee that they would pass binary data.
>
> I believe that programs reading from stdin are supposed to assume the
> text-mode semantic for the handles and behave accordingly. You've
> mentioned "cat" and "gzip" doing that very thing. Think there might be a
> reason for that?
Indeed, it's theoretically right that any programs which perform binary
I/O should set stdin/stdout as binary mode for portability. But
practically, it will be a heavy work to check that all programs on our
system follow the rule, and I think the check can't be perfect. I'd
rather keep all my scripts as LF than break my data by some programs
like base64, so I will continue to use the customized zsh.
PS: for base64, I will report the problem to bug-coreutils list later.
--
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
- Raw text -