[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Latin1 language environment breaks Cygwin shell buffer

From: Eli Zaretskii
Subject: Re: Latin1 language environment breaks Cygwin shell buffer
Date: Sat, 30 Mar 2002 21:10:10 +0300

> From: Eric Hanchrow <address@hidden>
> Date: 30 Mar 2002 08:32:39 -0800
> On a Cygwin system (excruciatingly painful details below), type
> `runemacs' at the shell, and then evaluate these four forms in order
> (adjust the name of the "bash" program as needed for your system):

I don't have Cygwin installed, so I can only speculate about this.
Therefore, please take what's below with a grain of salt.

> (set-language-environment "Latin-1")
> (setq shell-file-name         "c:/cygwin/bin/bash")
> (setq explicit-shell-file-name        "c:/cygwin/bin/bash")

You should probably use an explicit .exe extension in setting these
variables.  (Actually, I don't recommend setting these variables at
all in Emacs, but instead set up PATH and SHELL variables _outside_
Emacs so that the right shell is found.  But this is a different
issue, probably unrelated to your problems.)

> (shell)
> You will, not surprisingly, see a "*shell*" buffer appear.  Now switch
> to that buffer with C-x o, and hit the Enter key -- you'll see 
>       $ 
>       : command not found
> (You'll also see a lot of cruft from escape sequences in the Bash
> prompt; you may ignore those)

I rather think that this ``cruft'' should not be ignored, but instead
closely scrutinized.  I suspect that, in a Latin-1 environment, Emacs
finds in that cruft something that utterly confuses the shell mode.

How about if you disable all the prompt rigamarole in your Bash, and
see if that helps?

Also, what about your settings of process-coding-system?  What is it
in both language environments you used, and does it help to use
set-buffer-process-coding-system in the shell buffer so that Emacs
decodes Bash output with undecided-dos?

> I expected my choice of language environment to have no effect on the
> functioning of the shell.

The language environment sets the defaults for decoding subprocess
I/O, so there are valid reasons you should assume it does in fact have
effect on the interaction between Bash and the shell buffer.

> I think that the shell is "seeing" a carriage-return at the end of the
> input line, and complaining about it

It is (or, rather, should be) normal for the Cygwin Bash to see a
CR-LF pair at the end of each line.  It shouldn't complain about it,
but should rather DTRT: remove the CR and act on the rest as a normal
text line.

You might wish to experiment with mounting your filesystems in binary
(instead of text) mode.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]