[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Unwanted `^A' and `^B' characters in bash prompt.
|
From: |
Lute Kamstra |
|
Subject: |
Unwanted `^A' and `^B' characters in bash prompt. |
|
Date: |
Tue, 20 May 2003 11:57:12 +0200 |
|
User-agent: |
Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) |
Dear people,
In February, we had a discussion about `^A' and `^B' characters
showing up in the bash prompt when using Emacs' shell mode. I
attached the thread for easy reference.
In short, as of Emacs 21.3, bash is invoked by shell mode with the
`--noediting' option. Recent versions of bash have a bug that can
result in control A and control B characters showing up in its prompt
when it is invoked with `--noediting'. As I understand it, this
happens when ANSI escape sequences are used in the bash prompt to
color it.
The discussion ended with Andreas writing a bug report to the bash
maintainers. This, however, does not solve the problem for users of
current versions of bash (including me :-( ). So I wrote a small
function that removes the unwanted `^A' and `^B' characters from the
bash prompt. Shall I put this function in etc/PROBLEMS as shown in
the patch below?
Regards,
Lute.
*** etc/PROBLEMS.~1.151.~ 2003-05-05 18:39:58.000000000 +0200
--- etc/PROBLEMS 2003-05-20 11:46:57.000000000 +0200
***************
*** 1,6 ****
--- 1,29 ----
This file describes various problems that have been encountered
in compiling, installing and running GNU Emacs.
+ * Shell mode shows `^A' and `^B' characters in bash prompt.
+
+ Due to a bug in some versions of bash, unwanted `^A' and `^B'
+ characters may show up in the prompt. If you experience this problem
+ while using Emacs' shell mode, you can put the following in your
+ `.emacs' file get rid of the unwanted characters:
+
+ (add-hook 'shell-mode-hook
+ '(lambda ()
+ (add-hook 'comint-output-filter-functions
+ 'shell-filter-ctrl-a-ctrl-b nil t)))
+
+ (defun shell-filter-ctrl-a-ctrl-b (string)
+ "Remove `^A' and `^B' characters from comint output.
+ These characters may show up in the prompt of bash, due to a bug in
+ bash. If you experience this problem, put this function in
+ `comint-output-filter-functions'."
+ (let ((pmark (process-mark (get-buffer-process (current-buffer)))))
+ (save-excursion
+ (goto-char (or comint-last-output-start (point-min)))
+ (while (re-search-forward "[\C-a\C-b]" pmark t)
+ (replace-match "")))))
+
* Emacs crashes on Mac OS X (Carbon) after system software upgrade.
This problem seems to be now solved by Steven Tamm's patch to
--- Begin Message ---
|
Subject: |
Topics |
Topics:
Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95.
--- End Message ---
--- Begin Message ---
|
Subject: |
Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Fri, 07 Feb 2003 18:17:40 +0100 |
Dear people,
I experience some problems with a colored prompt in shell mode.
I've defined a prompt for bash like this.
,----[ .bashrc ]
|
PS1="\[\033[1;34m\][\[\033[1;31m\]\s-\v\[\033[1;34m\]|\[\033[1;31m\]\h\[\033[1;34m\]|\[\033[1;31m\]\W\[\033[1;34m\]]>\[\033[0m\]
"
`----
As you can see, it's filled with escape sequences to get colored text.
The idea is to get a prompt like this:
[bash-2.04|occarina|lute]>
The `[', `|', `|', `]' and `>' should be blue, the other text red.
I configured Emacs like this.
,----[ .emacs ]
| ;;;-------------------------------------------------------------------
| ;;; Shell mode.
| ;;;-------------------------------------------------------------------
|
| ;; We sure want to use bash.
| (setq explicit-shell-file-name "/bin/bash")
|
| ;; If you can't stop ANSI escape sequences, use them.
| (autoload 'ansi-color-for-comint-mode-on "ansi-color" nil t)
| (add-hook 'shell-mode-hook 'ansi-color-for-comint-mode-on)
|
| ;; This is what my shell prompt looks like.
| (setq shell-prompt-pattern "\\[[^|]+|[^|]+|[^|]+\\]> ")
`----
With Emacs 21.2 this setup works like a charm: I get the expected text
and colors in shell mode. However, when I use Emacs 21.2.95, the
prompt looks like this:
^A^B[^A^Bbash-2.04^A^B|^A^Boccarina^A^B|^A^Blute^A^B]>^A^B
There are lots of control A and control B characters interspersed that
should not be there. (To be able to send this mail, I replaced the
single control characters by double character lookalikes.) The is
color right, though, in the sense that all text that is supposed to be
there has the right color. The surplus control A and control B
characters have the same color of the normal text they directly
precede or succeed.
For comparison, in Emacs 21.2.95 and Emacs 21.2, doing a M-x
ansi-color-for-comint-mode-off results in an uncolored prompt that
look like this:
^A^[[1;34m^B[^A^[[1;31m^Bbash-2.04^A^[[1;34m^B|^A^[[1;31m^Boccarina^A^[[1;34m^B|^A^[[1;31m^Blute^A^[[1;34m^B]>^A^[[0m^B
and like this:
^[[1;34m[^[[1;31mbash-2.04^[[1;34m|^[[1;31moccarina^[[1;34m|^[[1;31mlute^[[1;34m]>^[[0m
respectively.
When I change the bash prompt and use:
PS1="[\s-\v|\h|\W]> "
I get a normal, uncolored prompt in both Emacs 21.2.95 and Emacs 21.2.
To be complete, here is the usual M-x report-emacs-bug information:
In GNU Emacs 21.2.95.1 (i686-pc-linux-gnu, Motif Version 2.1.30)
of 2003-02-07 on occarina.pna.cwi.nl
configured using `configure --prefix=/export/scratch1/lute/emacs-pretest
--exec-prefix=/export/scratch1/lute/emacs-pretest --with-x-toolkit=motif
--with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-x'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US
locale-coding-system: iso-latin-1
default-enable-multibyte-characters: t
I'll try to find out what is causing this problem.
Regards,
Lute Kamstra.
--
Lute Kamstra <address@hidden>
CWI department PNA4
Room M233 phone (+31) 20 592 4214
[Echelon material: Vince Foster bluebird Sundevil]
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Sun, 09 Feb 2003 07:39:34 -0500 |
Can you determine whether the shell is outputting these ^A and ^B
characters?
Francesco, do you see anything in the change logs that might account
for this? I don't, but I haven't updated since 4 Dec.
I suspect that the shell is outputting them, and I wonder if
something has changed in either the terminfo settings that Emacs tells
the shell to use, or some environment variable that controls the shell's
behavior.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Mon, 10 Feb 2003 10:49:25 +0100 |
Richard Stallman <address@hidden> writes:
> Can you determine whether the shell is outputting these ^A and ^B
> characters?
I don't know of a way to determine what the shell is outputting. Can
somebody give me a suggestion on how to do this?
Regards,
Lute.
--
Lute Kamstra <address@hidden>
CWI department PNA4
Room M233 phone (+31) 20 592 4214
[Echelon material: espionage Ruby Ridge AMEMB]
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Mon, 10 Feb 2003 19:32:16 +0100 |
>> Can you determine whether the shell is outputting these ^A and ^B
>> characters?
Following are hints, not proofs. I am still investigating, but now I'm
going home, so I'll let you know what I found. By the way, a shorter
way to reproduce the problem is by doing, at the shell pronpt in a shell
buffer:
PS1="\[\033[1;34m\][\h|\[\033[1;31m\]\W\[\033[1;34m\]]>\[\033[0m\] "
Also, the set of change logs from 21.2.90 to 21.2.91 is at
<ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-21.2.91.announce>. The
problem should be there, as Lute says that 21.2.90 works, while 21.2.91
does not.
>I don't know of a way to determine what the shell is outputting. Can
>somebody give me a suggestion on how to do this?
Apparently the shell does output those characters.
I did not verify this directly, but rather by reading the bash source.
It seems that bash puts placeholders around non printable strings, and
strips them before outputting the string. For some reason, these are
not stripped in our case.
I found this in parse.y:
================================================================
#if defined (READLINE)
case '[':
case ']':
temp = (char *)xmalloc (3);
temp[0] = '\001';
temp[1] = (c == '[') ? RL_PROMPT_START_IGNORE :
RL_PROMPT_END_IGNORE;
temp[2] = '\0';
goto add_string;
#endif /* READLINE */
================================================================
this in lib/readline/readline.h:
================================================================
/* Definitions available for use by readline clients. */
#define RL_PROMPT_START_IGNORE '\001'
#define RL_PROMPT_END_IGNORE '\002'
================================================================
and this in lib/readline/display.c:
================================================================
/* Expand the prompt string S and return the number of visible
characters in *LP, if LP is not null. This is currently more-or-less
a placeholder for expansion. LIP, if non-null is a place to store the
index of the last invisible character in the returned string. NIFLP,
if non-zero, is a place to store the number of invisible characters in
the first prompt line. */
/* Current implementation:
\001 (^A) start non-visible characters
\002 (^B) end non-visible characters
all characters except \001 and \002 (following a \001) are copied to
the returned string; all characters except those between \001 and
\002 are assumed to be `visible'. */
static char *
expand_prompt (pmt, lp, lip, niflp)
char *pmt;
int *lp, *lip, *niflp;
{
char *r, *ret, *p;
int l, rl, last, ignoring, ninvis, invfl;
/* Short-circuit if we can. */
if (strchr (pmt, RL_PROMPT_START_IGNORE) == 0)
{
r = savestring (pmt);
if (lp)
*lp = strlen (r);
return r;
}
l = strlen (pmt);
r = ret = (char *)xmalloc (l + 1);
invfl = 0; /* invisible chars in first line of prompt */
for (rl = ignoring = last = ninvis = 0, p = pmt; p && *p; p++)
{
/* This code strips the invisible character string markers
RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE */
if (*p == RL_PROMPT_START_IGNORE)
{
ignoring++;
continue;
}
else if (ignoring && *p == RL_PROMPT_END_IGNORE)
{
ignoring = 0;
last = r - ret - 1;
continue;
}
else
{
*r++ = *p;
if (!ignoring)
rl++;
else
ninvis++;
if (rl == _rl_screenwidth)
invfl = ninvis;
}
}
if (rl < _rl_screenwidth)
invfl = ninvis;
*r = '\0';
if (lp)
*lp = rl;
if (lip)
*lip = last;
if (niflp)
*niflp = invfl;
return ret;
}
/* Just strip out RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE from
PMT and return the rest of PMT. */
char *
_rl_strip_prompt (pmt)
char *pmt;
{
char *ret;
ret = expand_prompt (pmt, (int *)NULL, (int *)NULL, (int *)NULL);
return ret;
}
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Tue, 11 Feb 2003 17:25:10 -0500 |
Apparently the shell does output those characters.
I suspect that some envvar must have be telling it to do so.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Mon, 10 Feb 2003 17:39:40 -0500 |
I don't know of a way to determine what the shell is outputting. Can
somebody give me a suggestion on how to do this?
Sorry, I don't know.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Mon, 10 Feb 2003 11:46:49 +0100 |
Richard Stallman <address@hidden> writes:
> Francesco, do you see anything in the change logs that might account
> for this? I don't, but I haven't updated since 4 Dec.
I tested a few old pretests and found out that the problem first
occurred in Emacs 21.2.91. In Emacs 21.2.90, the shell prompt looks
fine.
Regards,
Lute.
--
Lute Kamstra <address@hidden>
CWI department PNA4
Room M233 phone (+31) 20 592 4214
[Echelon material: CDC e-bomb investigation]
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Tue, 11 Feb 2003 02:49:55 -0500 |
I tested a few old pretests and found out that the problem first
occurred in Emacs 21.2.91. In Emacs 21.2.90, the shell prompt looks
fine.
Can you identify the Emacs change that did it?
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Tue, 11 Feb 2003 11:10:53 +0100 |
> I tested a few old pretests and found out that the problem first
> occurred in Emacs 21.2.91. In Emacs 21.2.90, the shell prompt looks
> fine.
I just built 21.2.90 and 21.2.91, and I see no difference in their
behaviour on my box. Both show the ^A and ^B characters, exactly as the
latest pretest does. Moreover, I tried with the stock Debian 21.2
package, and it behaves the same.
In conclusion, 21.2 and all pretests behave in the same way on my box.
Moreover, I cannot tell whether this is an Emacs bug or a bash bug.
I'll try to investigate some more.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
11 Feb 2003 12:31:23 +0100 |
Richard Stallman <address@hidden> writes:
> I tested a few old pretests and found out that the problem first
> occurred in Emacs 21.2.91. In Emacs 21.2.90, the shell prompt looks
> fine.
>
> Can you identify the Emacs change that did it?
Yes. The change in shell.el is causing the change in behavior. With
Emacs 21.2.91, a new user option is introduced in Emacs. Here's the
changelog entry:
,----
| 2002-07-30 Andreas Schwab <address@hidden>
|
| * shell.el (explicit-bash-args): New user option.
`----
The user option looks like this:
,----[ shell.el; lines 278-284 ]
| (defcustom explicit-bash-args
| ;; Tell bash not to use readline.
| '("--noediting" "-i")
| "*Args passed to inferior shell by M-x shell, if the shell is bash.
| Value is a list of strings, which may be nil."
| :type '(repeat (string :tag "Argument"))
| :group 'shell)
`----
With my setup, this causes bash to be started with the "--noediting"
option (in Emacs 21.2.91), while this was not the case before (in
Emacs 21.2.90). The bash man pages say:
,----[ man bash ]
| --noediting
| Do not use the GNU readline library to read command
| lines when the shell is interactive.
|
`----
I'm not sure what Andreas Schwab's idea behind this change was. If I
revert the change, by changing the above part of shell.el into this:
,----[ shell.el; lines 278-284 ]
| (defcustom explicit-bash-args
| ;; Tell bash not to use readline.
| '("-i")
| "*Args passed to inferior shell by M-x shell, if the shell is bash.
| Value is a list of strings, which may be nil."
| :type '(repeat (string :tag "Argument"))
| :group 'shell)
`----
then the ^A and ^B characters don't appear anymore and things work
fine again as they did in Emacs 21.2.90.
I also tried "bash --noediting" in an xterm and a gnome-terminal. An
xterm (XFree86 4.0.1h(149)) shows the same behavior as Emacs does, in
the sense that it prints extra control characters. The gnome-terminal
(1.2.4) work fine, however. Apparently, it looks for the ^A and ^B
characters and strips them.
Regards,
Lute.
--
Lute Kamstra <address@hidden>
CWI department PNA4
Room M233 phone (+31) 20 592 4214
[Echelon material: LABLINK Noriega RSA]
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Tue, 11 Feb 2003 12:42:26 +0100 |
>the sense that it prints extra control characters. The gnome-terminal
>(1.2.4) work fine, however. Apparently, it looks for the ^A and ^B
>characters and strips them.
Apparently this is what the Linux console does too. In fact, I can see
this on a Linux console:
$ echo -e "##\001\040##"
## ##
This is true for all non printable characters that I tried.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Tue, 11 Feb 2003 13:00:29 +0100 |
Lute Kamstra <address@hidden> writes:
|> Richard Stallman <address@hidden> writes:
|>
|> > I tested a few old pretests and found out that the problem first
|> > occurred in Emacs 21.2.91. In Emacs 21.2.90, the shell prompt looks
|> > fine.
|> >
|> > Can you identify the Emacs change that did it?
|>
|> Yes. The change in shell.el is causing the change in behavior. With
|> Emacs 21.2.91, a new user option is introduced in Emacs. Here's the
|> changelog entry:
|>
|> ,----
|> | 2002-07-30 Andreas Schwab <address@hidden>
|> |
|> | * shell.el (explicit-bash-args): New user option.
|> `----
|>
|> The user option looks like this:
|>
|> ,----[ shell.el; lines 278-284 ]
|> | (defcustom explicit-bash-args
|> | ;; Tell bash not to use readline.
|> | '("--noediting" "-i")
|> | "*Args passed to inferior shell by M-x shell, if the shell is bash.
|> | Value is a list of strings, which may be nil."
|> | :type '(repeat (string :tag "Argument"))
|> | :group 'shell)
|> `----
|>
|> With my setup, this causes bash to be started with the "--noediting"
|> option (in Emacs 21.2.91), while this was not the case before (in
|> Emacs 21.2.90). The bash man pages say:
|>
|> ,----[ man bash ]
|> | --noediting
|> | Do not use the GNU readline library to read command
|> | lines when the shell is interactive.
|> |
|> `----
|>
|> I'm not sure what Andreas Schwab's idea behind this change was.
This change is needed to get control characters passed properly to bash.
Otherwise they are intercepted by readline, which is not what we want.
|> then the ^A and ^B characters don't appear anymore and things work
|> fine again as they did in Emacs 21.2.90.
Do you have a custom $PS1? Does it contains empty \[\] sequences? Then
this is a bug in bash.
Andreas.
--
Andreas Schwab, SuSE Labs, address@hidden
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Tue, 11 Feb 2003 13:20:11 +0100 |
>Do you have a custom $PS1? Does it contains empty \[\] sequences? Then
>this is a bug in bash.
They are not empty. You can reproduce this by doing:
PS1="\[\033[1;34m\][\h|\[\033[1;31m\]\W\[\033[1;34m\]]>\[\033[0m\] "
in a shell buffer and then
M-x ansi-color-for-comint-mode-on RET
If this is a bug in bash, should we work around it as the Linux console
and other terminal emulators do by discarding non printable characters
in shell mode?
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
11 Feb 2003 13:30:53 +0100 |
Andreas Schwab <address@hidden> writes:
[...]
> |> I'm not sure what Andreas Schwab's idea behind this change was.
>
> This change is needed to get control characters passed properly to bash.
> Otherwise they are intercepted by readline, which is not what we want.
>
> |> then the ^A and ^B characters don't appear anymore and things work
> |> fine again as they did in Emacs 21.2.90.
>
> Do you have a custom $PS1?
I do.
> Does it contains empty \[\] sequences? Then this is a bug in bash.
It does have \[\] sequences. They contain ANSI escape sequences to
set the color. Do you consider this empty?
To be precise, my bash prompt is defined by:
PS1="\[\033[1;34m\][\[\033[1;31m\]\s-\v\[\033[1;34m\]|\[\033[1;31m\]\h\[\033[1;34m\]|\[\033[1;31m\]\W\[\033[1;34m\]]>\[\033[0m\]
"
to give a colored prompt that looks like this:
[bash-2.04|occarina|lisp]>
Lute.
--
Lute Kamstra <address@hidden>
CWI department PNA4
Room M233 phone (+31) 20 592 4214
[Echelon material: Elvis Cocaine NORAD]
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Tue, 11 Feb 2003 17:23:15 +0100 |
Lute Kamstra <address@hidden> writes:
|> Andreas Schwab <address@hidden> writes:
|>
|> [...]
|>
|> > |> I'm not sure what Andreas Schwab's idea behind this change was.
|> >
|> > This change is needed to get control characters passed properly to bash.
|> > Otherwise they are intercepted by readline, which is not what we want.
|> >
|> > |> then the ^A and ^B characters don't appear anymore and things work
|> > |> fine again as they did in Emacs 21.2.90.
|> >
|> > Do you have a custom $PS1?
|>
|> I do.
|>
|> > Does it contains empty \[\] sequences? Then this is a bug in bash.
|>
|> It does have \[\] sequences. They contain ANSI escape sequences to
|> set the color. Do you consider this empty?
No, but it seems the \[\] processing is broken with --noediting. The ^A
and ^B markers are internal quoting characters in bash strings.
Andreas.
--
Andreas Schwab, SuSE Labs, address@hidden
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
11 Feb 2003 14:25:03 +0100 |
Lute Kamstra <address@hidden> writes:
> Richard Stallman <address@hidden> writes:
>
> > I tested a few old pretests and found out that the problem first
> > occurred in Emacs 21.2.91. In Emacs 21.2.90, the shell prompt looks
> > fine.
> >
> > Can you identify the Emacs change that did it?
>
> Yes. The change in shell.el is causing the change in behavior. With
> Emacs 21.2.91, a new user option is introduced in Emacs. Here's the
> changelog entry:
>
> ,----
> | 2002-07-30 Andreas Schwab <address@hidden>
> |
> | * shell.el (explicit-bash-args): New user option.
> `----
>
> The user option looks like this:
>
> ,----[ shell.el; lines 278-284 ]
> | (defcustom explicit-bash-args
> | ;; Tell bash not to use readline.
> | '("--noediting" "-i")
> | "*Args passed to inferior shell by M-x shell, if the shell is bash.
> | Value is a list of strings, which may be nil."
> | :type '(repeat (string :tag "Argument"))
> | :group 'shell)
> `----
This is unrelated to the actual problem, but it reminds me that I
installed the following fix on CVS head to make this work with
bash 1.x which doesn't grook --noediting:
(defcustom explicit-bash-args
;; Tell bash not to use readline, except for bash 1.x which doesn't grook
--noediting.
;; Bash 1.x has -nolineediting, but process-send-eof cannot terminate bash if
we use it.
(let* ((prog (or (and (boundp 'explicit-shell-file-name)
explicit-shell-file-name)
(getenv "ESHELL") shell-file-name))
(name (file-name-nondirectory prog)))
(if (and (not purify-flag)
(equal name "bash")
(file-executable-p prog)
(string-match "bad option"
(shell-command-to-string (concat prog "
--noediting"))))
'("-i")
'("--noediting" "-i")))
"*Args passed to inferior shell by M-x shell, if the shell is bash.
Value is a list of strings, which may be nil."
:type '(repeat (string :tag "Argument"))
:group 'shell)
We should probably merge the fix to the RC branch.
--
Kim F. Storm http://www.cua.dk
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Wed, 12 Feb 2003 15:32:44 -0500 |
How about talking with the Bash maintainers to see if this is a bug in
Bash? It might be. Or it might be a feature, in which case the Emacs
change is a bug.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Thu, 13 Feb 2003 12:51:59 +0100 |
Richard Stallman <address@hidden> writes:
|> How about talking with the Bash maintainers to see if this is a bug in
|> Bash? It might be. Or it might be a feature, in which case the Emacs
|> change is a bug.
I have now submitted a bug report for bash, see
<http://mail.gnu.org/archive/html/bug-bash/2003-02/msg00046.html>.
Andreas.
--
Andreas Schwab, SuSE Labs, address@hidden
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Thu, 13 Feb 2003 13:17:58 +0100 |
Andreas Schwab <address@hidden> writes:
> Richard Stallman <address@hidden> writes:
>
> |> How about talking with the Bash maintainers to see if this is a bug in
> |> Bash? It might be. Or it might be a feature, in which case the Emacs
> |> change is a bug.
>
> I have now submitted a bug report for bash, see
> <http://mail.gnu.org/archive/html/bug-bash/2003-02/msg00046.html>.
This should solve the problem for future versions of bash. Thanks!
Maybe it's a good idea to fix the problem for current version(s) of
bash as well and let Emacs filter out any ^A and ^B characters that
appear in the prompt.
Lute.
--
Lute Kamstra <address@hidden>
CWI department PNA4
Room M233 phone (+31) 20 592 4214
[Echelon material: SHA Verisign plutonium]
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Thu, 20 Feb 2003 15:07:04 +0100 |
Andreas, can you tell us about the state of the suspect bash bug?
Richard, should we consider this a show stopper for Emacs 21.3?
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Fri, 21 Feb 2003 13:41:04 +0100 |
Francesco Potorti` <address@hidden> writes:
|> Andreas, can you tell us about the state of the suspect bash bug?
No answer yet.
Andreas.
--
Andreas Schwab, SuSE Labs, address@hidden
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Fri, 21 Feb 2003 16:43:40 -0500 |
Richard, should we consider this a show stopper for Emacs 21.3?
Definitely not.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Mon, 10 Feb 2003 15:52:27 +0100 |
>I've defined a prompt for bash like this.
>
>,----[ .bashrc ]
>|
>PS1="\[\033[1;34m\][\[\033[1;31m\]\s-\v\[\033[1;34m\]|\[\033[1;31m\]\h\[\033[1;34m\]|\[\033[1;31m\]\W\[\033[1;34m\]]>\[\033[0m\]
> "
>`----
I do not know why you put all those \[ and \] in there. I tried to
remove all of them and I got a working prompt, like this:
PS1="\033[1;34m[\033[1;31m\s-\v\033[1;34m|\033[1;31m\h\033[1;34m|\033[1;31m\W\033[1;34m]>\033[0m
"
Can you confirm this?
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: Problems with ANSI colors in shell mode in Emacs 21.2.95. |
|
Date: |
Mon, 10 Feb 2003 16:33:48 +0100 |
Francesco Potorti` <address@hidden> writes:
> >I've defined a prompt for bash like this.
> >
> >,----[ .bashrc ]
> >|
> >PS1="\[\033[1;34m\][\[\033[1;31m\]\s-\v\[\033[1;34m\]|\[\033[1;31m\]\h\[\033[1;34m\]|\[\033[1;31m\]\W\[\033[1;34m\]]>\[\033[0m\]
> > "
> >`----
>
> I do not know why you put all those \[ and \] in there.
,----[ man bash; PROMPTING ]
| \[ begin a sequence of non-printing characters,
| which could be used to embed a terminal con
| trol sequence into the prompt
| \] end a sequence of non-printing characters
`----
> I tried to remove all of them and I got a working prompt, like this:
>
> PS1="\033[1;34m[\033[1;31m\s-\v\033[1;34m|\033[1;31m\h\033[1;34m|\033[1;31m\W\033[1;34m]>\033[0m
> "
>
> Can you confirm this?
This indeed works in the shell mode of Emacs 21.2.95. However, things
go terribly wrong when I use this setting for PS1 in combination with
xterm (XFree86 4.0.1h(149)) or gnome-terminal (1.2.4). For example,
the cursor is not positioned at the end of the prompt anymore.
Regards,
Lute.
--
Lute Kamstra <address@hidden>
CWI department PNA4
Room M233 phone (+31) 20 592 4214
[Echelon material: CIDA president NSA]
--- End Message ---
- Unwanted `^A' and `^B' characters in bash prompt.,
Lute Kamstra <=