[Eric Hanchrow <offby1@blarg.net>] Re: Latin1 language environment breaks Cygwin shell buffer

[Eric Hanchrow <offby1@blarg.net>] Re: Latin1 language environment breaks Cygwin shell buffer

[Eric Hanchrow]

[-- Attachment #1: Type: text/plain, Size: 96 bytes --]

I'm forwarding this because I forgot to keep the mailing list on the
Cc: line as Eli requested


[-- Attachment #2: Type: message/rfc822, Size: 2356 bytes --]

From: Eric Hanchrow <offby1@blarg.net>
To: Eli Zaretskii <eliz@is.elta.co.il>
Subject: Re: Latin1 language environment breaks Cygwin shell buffer
Date: 31 Mar 2002 00:02:11 -0800
Message-ID: <87y9g9qi64.fsf@blarg.net>

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

    Eli> AFAIK, `emacs' does not open a console window for quite some
    Eli> time.  

You're right.  Old habits die hard.  But: `emacs' itself also sets
those variables.

    >> Also, what about your settings of process-coding-system?  What
    >> is it in both language environments you used

        default-process-coding-system's value is
        (iso-latin-1-dos . iso-latin-1-dos)

and

        process-coding-system-alist's value is nil

    Eli> Then it's probably not something related to CR characters ...
    Eli> how come `od' shows \r characters in the output of `echo'?

I'm 99% sure it is indeed related to CR characters; I think `od' shows
\r in the output of `echo' because they were passed as *input* to
`echo'.

Here's another experiment I did that will convince you (at least, it
convinced me):  I typed

        ls RET

, three keystrokes, into the buffer, and saw (as I described before)

        : command not found

... precisely what I see if, on a GNU/Linux system (also Emacs 21.2,
bash 2.05a.0, same .emacs.el file) I type

        ls C-q C-v C-q C-m

(control-V is the shell's "quote-the-next-character" character)

So Bash on Win32 is behaving precisely as Bash on GNU/Linux behaves,
if I quote the carriage-return.

Similarly, if I type

        ls SPC RET

to Win32 Emacs, I see

        : No such file or directory

... precisely what I see on GNU/Linux when I type

        ls SPC C-q C-v C-q C-m

In other words, `ls' is getting a single argument, of a single
character, namely carriage-return.  Why Bash isn't treating it as
whitespace is a mystery.

    Eli> Something strange is going on here, and you probably need a
    Eli> Cygwin guru to help you out.  I suggest to ask on the Cygwin
    Eli> mailing list.

That makes sense.
 

[-- Attachment #3: Type: text/plain, Size: 74 bytes --]



-- 
PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5  C8BD 6337 0041 C01C 5276

Re: [Eric Hanchrow <offby1@blarg.net>] Re: Latin1 language environment breaks Cygwin shell buffer

[Eli Zaretskii]

On 31 Mar 2002, Eric Hanchrow wrote:

    >> Also, what about your settings of process-coding-system?  What
    >> is it in both language environments you used

        default-process-coding-system's value is
        (iso-latin-1-dos . iso-latin-1-dos)

   and

        process-coding-system-alist's value is nil

Given the fact that Cygwin mounts your volumes in binary mode, I suggest 
to try setting process-coding-system to (iso-latin-1-dos . iso-latin-1-unix).

Re: [Eric Hanchrow <offby1@blarg.net>] Re: Latin1 language environment breaks Cygwin shell buffer

[Eric Hanchrow]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:

    Eli> Given the fact that Cygwin mounts your volumes in binary
    Eli> mode, I suggest to try setting process-coding-system to
    Eli> (iso-latin-1-dos .  iso-latin-1-unix).

Setting default-process-coding-system to (iso-latin-1-dos .
iso-latin-1-unix), and then killing the old shell buffer and making a
new one, fixed the problem.

-- 
PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5  C8BD 6337 0041 C01C 5276

Re: [Eric Hanchrow <offby1@blarg.net>] Re: Latin1 language environment breaks Cygwin shell buffer

[Eli Zaretskii]

> From: Eric Hanchrow <offby1@blarg.net>
> Date: 31 Mar 2002 08:17:07 -0800
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
>     Eli> Given the fact that Cygwin mounts your volumes in binary
>     Eli> mode, I suggest to try setting process-coding-system to
>     Eli> (iso-latin-1-dos .  iso-latin-1-unix).
> 
> Setting default-process-coding-system to (iso-latin-1-dos .
> iso-latin-1-unix), and then killing the old shell buffer and making a
> new one, fixed the problem.

Thanks for testing.

So it sounds like Emacs on Windows should somehow sense that the
Cygwin port of Bash is used, and if so, set the EOL conversion
appropriately.  Unfortunately, I don't know how to do the test for
that correctly.  Can you please see if mounting the filesystem in
text mode changes anything in this puzzle?

Re: [Eric Hanchrow <offby1@blarg.net>] Re: Latin1 language environment breaks Cygwin shell buffer

[Eric Hanchrow]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

    Eli> So it sounds like Emacs on Windows should somehow sense that
    Eli> the Cygwin port of Bash is used, and if so, set the EOL
    Eli> conversion appropriately.  

Sounds reasonable.
                                    
    Eli> Can you please see if mounting the filesystem in text mode
    Eli> changes anything in this puzzle?

It doesn't affect what I see in the shell.

-- 
PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5  C8BD 6337 0041 C01C 5276