Talk:Bash/Prompt customization

From ArchWiki
< Talk:Bash
Revision as of 17:06, 6 November 2010 by DJPohly (Talk | contribs) (Text entry color: new section)

Jump to: navigation, search

Return value visualization

The return value visualization stuff didn't quite work right for me. The command history prints out funny (bits of old command prefixes stay displayed), and also long lines behaved oddly (wrapped back to start etc.).

I think the trouble maybe coming from echo'ing out color commands with one echo then putting out the characters to reset the font elsewhere. I asked on the bash list and ended up doing this:

   # Make the prompt dark red when the previous command has succeeded, or
   # bright green when it has failed (in keeping with the slightly backwards
   # way exit codes work :).
   red=$(tput setaf 1)
   bright_green=$(tput bold; tput setaf 2)
   reset=$(tput sgr0)
   # Namespace'ed last user command exit status.  We need this I think because
   # the tput commands in the subshells end up resetting $?.
   colors=("$red" "$bright_green")
   PS1='\[${colors[$? != 0]}\]$(if [ $MYPROMPT_LUCES != 0 ]; then \
                                    echo "$MYPROMPT_LUCES "; \
                                fi)\$\[$reset\] '

which displays prompts following successful commands in dark red, and prompts following failing commands in bright green with the exit code shown.

— Preceding unsigned comment added by Bkerin

There is another, very simple method to get it work without problems with breaking lines. Rename PS1 to _PS1 in .bashrc and add this lines after _PS1 variable:

   PROMPT_COMMAND='RET=$?; if [[ $RET -eq 0 ]]; then export PS1="${RET_SUCC} ${_PS1}"; else export PS1="${RET_FAIL} ${_PS1}"; fi'

In this example RET_SUCC is , and RET_FAIL is . These symbols does not work with text terminal. To fix this, replace first 2 lines with this:

   if [ "$TERM" = "linux" ]

This is only an example, it is possible to add anything that PS1 accepts using this method.

— Preceding unsigned comment added by Noctivivans


This article cries out for examples. It is tough to tell if one would want to try any of these until one sees an example of what the outcome might be, should it be tried. I'll bet a lot of people are a little hesitant to try them. - KitchM 13:40, 12 April 2010 (EDT)

I went ahead and added previews of some of the simpler prompts. As an Archer, you're encouraged to try random stuff just to see what happens. Don't be hesitant, just have fun! --DJPohly 02:11, 13 April 2010 (EDT)
Very nice, indeed! Thank you very much. This will help immensely.
This is one Archer that has learned that there is no difference between Arch and any other distro or OS when it comes to the ability to screw things up. I am very hesitant. There are so many problems, that I am surprised that people are not having more problems with their systems. On the other hand, I must assume that people don't use theirs as extensively as do I. In any case, the examples will clearly show a person what happens before they start changing things. I will dive right in. I love "zero defects" methods.
Thanks again. Keep up the great work. - KitchM 16:26, 13 April 2010 (EDT) I think that the previous one was better, IIRC you can put those things either in .bashrc or bash_profile. But I'm not sure so I post here and not revert it. Feel free to correct me. Karol 05:59, 26 May 2010 (EDT)

better delete "Advanced return value visualisation"

The promt in section "Advanced return value visualisation" cause only problems due wrong length calculation in bash.

$ echo $PS1
$(echo $RET) $(if  $RET = 0 ; then echo -ne "\[$GREEN\];)"; else echo -ne "\[$RED\];("; fi;) :

this will be expanded to

0 ;) : 

But bash think promt is as long as string "$(echo $RET) $(if $RET = 0 ; then echo -ne "\[$GREEN\];)"; else echo -ne "\[$RED\];("; fi;) :" and not as long as string " 0 ;) : ". This cause ugly corruption by multi line input.

Quote from here

...In addition to this change, we need to surround
all non-printing characters with special bash escape
sequences, "\[" and "\]". These sequences will tell
bash that the enclosed characters don't take up any
space on the line, which will allow word-wrapping to
continue to work properly. Without them, you'll end
up with a nice-looking prompt that will mess up the
screen if you happen to type in a command that
approaches the extreme right of the terminal. ...

--Nikel 18:31, 13 August 2010 (EDT)

Text entry color

I tested output redirection of several types (pipe, redirect, command substitution), and the output of the DEBUG trap was never included. So I simplified the instructions here and removed the hack warning. If you can give an example that breaks it, leave a comment here saying what it is (because I'm curious!) and go ahead and revert me. -- DJPohly 13:06, 6 November 2010 (EDT)