Bash prompt string looks for xterm-color, gnome terminal identifies as xterm

No; that'll kill it for the xterm-color users, then. Could do xterm|xterm-color)...

Either way, it's a poor way to check for color support; better to check the terminal database. I propose this version:

--- skel.bashrc.orig 2007-04-06 16:37:35.000000000 -0700
+++ skel.bashrc 2007-04-06 16:56:16.000000000 -0700
@@ -20,18 +20,19 @@
     debian_chroot=$(cat /etc/debian_chroot)
 fi

-# set a fancy prompt (non-color, unless we know we "want" color)
-case "$TERM" in
-xterm-color)
+# set a fancy prompt (color, when supported)
+
+if tput setaf 1 >&/dev/null
+then
+ # We have color support; assume it's compliant with Ecma-48
+ # (ISO/IEC-6429). (Lack of such support is extremely rare, and such
+ # a case would tend to support setf rather than setaf.)
     PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
- ;;
-*)
+else
+ # Color apparently unsupported (or don't have tput(!)). Issue
+ # prompt, sans color sequences
     PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
- ;;
-esac
-
-# Comment in the above and uncomment this below for a color prompt
-#PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
+fi

 # If this is an xterm set the title to user@host:dir
 case "$TERM" in

The spaces seem not to have come out quite right; attaching.

I'd be happy to roll a quick debdiff version, but not sure how fruitful that would be, since there's a good chance bash will be merged from upstream. Anyway, gonna subscribe ubuntu-main-sponsors so they're aware of the adjustment.

Matthias: can you please check the patch?

Given that bash is in /bin and tput in /usr/bin, it _might_ be a good idea to be paranoid and wrap the tput test with parens, so we shut bash up if it can't find it; just in case the user has /usr on a separate partition:

  if (tput setaf 1) >&/dev/null

Might not be a bad idea to actually /use/ tput, too, in the generated strings, on the off-chance that the terminal has non-standard control sequences for that (but that seems unlikely).

It should also be noted that when using gnome-terminal,

an env variable COLORTERM is set.

$ export | grep TERM
declare -x COLORTERM="gnome-terminal"
declare -x TERM="xterm"

It is a lot easier to look at that I think.

Interesting; but how portable is that to other terminals?

COLORTERM should be avoided because Xterm does not touch it. Therefore if you start a non-colorized xterm from within gnome-terminal, you end up with the COLORTERM environment variable set to 'gnome-terminal' for the non-colorized xterm.

If just checking for COLORTERM to be set to gnome-terminal also, there isn't much of a way for this to break on other terminals such as Xterm.

Hardy material.

I don't want to apply this; the focus in a terminal window is not the prompt, but the things what you are doing there. Having this by default turned on in every gnome-terminal and kterm makes me cry. Please change this so that it can be conditionally turned on (by modifying one line).

Matthias, perhaps I'm missing something, but the color prompt is _already_ on by default. The change isn't to activate color prompts by default, but to make it check for the right TERM variable. If you wish it not to be on by default, that should be a separate issue.

Micah Cowan schrieb:
> Matthias, perhaps I'm missing something, but the color prompt is
> _already_ on by default.

At least in the standard gnome-terminal settings it is off by default.

Well, right: because, as the bug indicates, gnome-terminal advertises itself as xterm rather than xterm-color.

So, for some terminals (xterm itself, perhaps?), color will be on by default, while in others it will be off. Better to make it consistently one way or the other for _all_ color-capable term emulators.

If you'd like to apply the patch, but comment _out_ the whole block of code, that seems fine (might irk a few non-gnome-terminal users that had been used to it, but I kind of doubt it: they can just uncomment it, and anyway they've hopefully already customized their .bashrc the way they like it, so wouldn't be affected by /etc/skel).

Er, or perhaps what you've already suggested. Guess my reading ability dropped after seeing the "I don't want to apply this", and matched the "change this so it can be conditionally turned on". :)

I would still tend to agree with your earlier analysis: the fact that it doesn't do what it's supposed to do is this bug, and the fact that it would be nice to be able to turn it off is a separate bug.

What would be a suitable mechanism for turning it off if desired? I don't particularly like the idea of using a signal file in the user's home directory. Since this is in .bashrc, the user might want to set an environment variable in their .bash_profile to turn off color options; would that be a suitable solution?

- if (tput setaf 1) >&/dev/null
+ if ! test "$BASH_NO_COLOR" && (tput setaf 1) >&/dev/null

I would also like to put that dreadful "alias ls='ls --color=auto'" inside this conditional. There may be other parts of the default .bashrc which ought to be similarly refactored into this conditional, too.

> What would be a suitable mechanism for turning it off if desired?

I'd still vote for commenting it out. It's a skeleton .bashrc file; the
user is expected to customize it. IIRC, bash-completion is handled in
this way.

I think a shell var conditional just wastes time on a conditional, both
for those that want the functionality, and those that don't. It's not
really a feature people will be toggling frequently.

On Sun, 06 Apr 2008 09:59:19 -0000, "Micah Cowan"
<email address hidden> said:
> > What would be a suitable mechanism for turning it off if desired?
>
> I'd still vote for commenting it out. It's a skeleton .bashrc file;
> the user is expected to customize it. IIRC, bash-completion is handled
> in this way.
>
> I think a shell var conditional just wastes time on a conditional,
> both for those that want the functionality, and those that don't. It's
> not really a feature people will be toggling frequently.

But if it's a complex conditional and/or complex pieces of interacting
code snippets all over the file, it's easy to screw up, and likely to
contain bugs, and likely to change in future releases of Ubuntu.
Ideally, the user should not have to backport bug fixes from the skel
file when they upgrade their system, and so, I think it's an important
desideratum that you can simply source /etc/skel/.bashrc from your own
.bashrc and still customize or override some parts of it.

It's not like one environment variable more is going to matter much for
a user who already uses bash-completion, which heavily pollutes the
environment with complex internal completion functions.

At least on Gutsy, completion is enabled by default.

/* era */

--
If this were a real .signature, it would suck less. Well, maybe not.

> So, for some terminals (xterm itself, perhaps?), color will be on by default, while in others it will be off

for xterm it is off by default as well.

This bug was fixed in the package bash - 3.2-0ubuntu16

---------------
bash (3.2-0ubuntu16) hardy; urgency=low

  * Remove /etc/skel/.bash_profile, if it is unmodified; if modified and
    /etc/skel/.profile is unmodifed, move .bash_profile to .profile.
    LP: #211406.
  * /etc/skel/.bashrc: Add an option to blurt a terminal window with a
    colored prompt. LP: #103929.
  * /etc/skel/.bashrc: Add color support for grep and friends (commented out
    by default). LP: #144632.
  * /etc/skel/.profile: Avoid the use of `~'. LP: #200283.
  * Add a shopt option compat31 to falls back to the behaviour of bash-3.1
    and earlier versions, in that quoting the string argument to the [[
    command's =~ +operator does not force string matching. LP: #110407.

 -- Matthias Klose <email address hidden> Tue, 15 Apr 2008 01:24:06 +0200

The implementation of this solution has a bug.
The variable that you leave to uncomment in the bashrc skel is force_colored_prompt. The variable you later check for is force_color_prompt.

The bug #223256 is about it and got a patch for solving that problem ( about name of variable and a typo in
current .bashrc file )

The bug is fixed in hardy

I assume that in this fix, the following comment got added as well?

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt

I'd like to disagree with the latter part of that comment ("the focus in ... not on the prompt"). Because most command output is non-colored (luckily), it can be nice to spot your previous prompt to quickly find the beginning of the output of the command.

Obviously not everyone wants this, and I do not propose to enable a colored prompt by default. But do I find it unnecessary to state the view that colored-prompt-users are Wrong(tm). I'd rather see that replaced with "... distract the user. it's a matter of personal preference. p.s. vi > emacs ;)"

> I'd like to disagree with the latter part of that comment ("the focus in
> ... not on the prompt").

It irritated me too. Colour simply helps when you are scanning the
screen, whether you are looking at the prompt or the output.

--
jean . .. .... //\\\oo///\\

The current version of skel/.bashrc in Intrepid is nonsense as regards this issue. We still have code that checks $TERM against "xterm-color", and enables the color prompt if so. This fails for most terminals, of course. Then we have a variable, force_color_prompt, which we may set to yes to *enable* a more sensible detection of a color-capable terminal, which, if we pass, sets up a color prompt.

This is nonsense because not only do we turn on the color prompt rather inconsistently for xterm-color, which is the old behavior that was deemed to be Wrong (and confusing and ineffective), but also the variable force_color_prompt does not in fact *force* anything. The check against xterm-color should be removed because it is no longer necessary. The force_color_prompt variable should be renamed enable_color_prompt, allow_color_prompt, or maybe conditional_color_prompt. Finally, the obnoxiously moralizing comment that color prompts are for lusers is entirely inappropriate and should be removed.

So, here's the $64,000 question; is a colored prompt default in Ubuntu when using a color-capable terminal or not?

I'm just advocating for some consistency here.

It seems odd to see

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color) color_prompt=yes;;
esac

followed by

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

To me that says 'the default behavior is not to give you a color prompt, unless you're using xterm-color, in which case we're going to give you one, even though the default behavior is never to give you colored prompts in all the other terminals that support color but don't happen to identify themselves as xterm-color.'

If we're going to say that colored prompts are not the default in Ubuntu, then I don't see why the chunk of code coloring xterm-color terminal prompts still exists. It's confusing to me to see a colored prompt when I log in from an OSX machine using iTerm, and then to see the color disappear when I launch a screen. Makes the user (makes me, anyway) feel like they must have done something wrong, because they have a colored prompt sometimes and not other times. Having no colored prompts altogether without changing the force_color_prompt variable seems more consistent. "I had no colored prompts, I changed the variable, all my prompts are colored."

Even though I eventually found the force_color_prompt variable, I don't like making changes to configuration files when I don't understand the rationale behind the code (workarounds = bad ; accepted config changes that will persist throughout updates = good). It also took a little chunk of my morning to figure this all out, and I'm trying to save everyone else the time :)

I also agree with those that think color prompts /should/ be the default in any terminal that supports it, considering power users are more likely to have a preference on color vs no color (and can easily change the variable), and considering I agree that a colored prompt does not distract nor take away from the output of a command, but in fact helps the user locate the beginning of the output of the last command. Having a different color for root vs non-root users (red vs green) would also supplement the $ vs # prompt and helps users be wary when they are logged in as root (though I'm thinking this was the behavior in Gentoo and might not happen in Ubuntu since it discourages root logins altogether).

Here's hoping the very simple block of script setting a colored prompts for xterm-color terminals can be removed. Simple instructions could be added to https://help.ubuntu.com/community/UsingTheTerminal or https://help.ubuntu.com/community/CommandlineHowto instructing users which variable to edit for colorless (or always colored) prompts. As for making people backport their .bashrc from /etc/skel, you're right, users shouldn't need to do this, and changing the /etc/skel/.bashrc won't affect existing users who have already configured colored prompts for themselves or are ha...

To add my two cents: I really would like a colored prompt if the terminal supports it - as a default. As pointed out before: The colored prompt allows to easily locate the beginning and the end of the output of a command.

This bug has been open for such a long time - please include a fix for 10.04, if it is possible.

Trying to introduce a cousin of mine to use the shell to work with git and latex on some school documents, I found it really hard to make him grasp the shell concepts easily. This was partly because of colors are not enabled by default. He just had problems finding out where he was after a command completed. Colored prompts make the shell much more easy to read.

If there are really people like Matthias Klose in #11, then they are power users that know how to fix things. Colors should be on by default to support normal users.

I also think the current behavior and naming of variables is inconsistent.
While searching for the meaning of the variables I found this bug and I'm shocked that it is open for such a long time but made such a little progress as it should be a very important one for ubuntu.

Most new people still fearing the terminal and feeling unwell using it. Colors can help here a lot and make the terminal easier to understand, especially for beginners.

As this is an important goal of ubuntu, it should be turned on by default as the previous writers noted.

How does non-color terminals deal with color prompts? If you `echo -e '\e[1;34mtest\e[0m'` on a terminal without support, does it come out garbled? If so, couldn't that be a test of color support? echo something with formatting, then check that the string output to stdout is only that between the formatting expressions. Or is it possible to use one of the solutions mentioned in http://stackoverflow.com/questions/2465425/how-do-i-determine-if-a-terminal-is-color-capable: `tput colors 2` or `man terminfo`?

"tput setaf" is the appropriate check to use, and was already present in my initial recommendation (via the first comment to this report), and in fact is what's currently being used (at least in Lucid) in /etc/skel/.bashrc (if force_color_prompt is set).

There's no way to do an echo/check stdout test as you suggest. It's the terminal itself that prevents the garbling, and there's no portable way to check whether a final output string was garbled or not, since there's no portable way to inspect the display contents on a terminal (AFAIK, for most terminals there's not even an unportable way).

Note that the difference between "xterm" and "xterm-color" has never been the difference between color support and no color support; it was intended to convey the difference between basic color support and extended (256) color support. That's why I thought it was silly to check for "xterm-color", but then only make use of basic colors that would work on "xterm" (no "-color") anyway. We still do that if force_color_prompt isn't set, and I still think it's silly (but then, I also think it's silly that gnome-terminal doesn't set TERM to xterm-color, since gnome-terminal does in fact support extended colors).

This must solve the problem i think. Instead of asking user about color prompt
i think we must ask them for non-colored prompt.
The patch is added