--- Begin Message ---
|
Subject: |
Re: Latin1 language environment breaks Cygwin shell buffer |
|
Date: |
31 Mar 2002 00:02:11 -0800 |
|
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 |
>>>>> "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.
--- End Message ---