Talk:Bash/Prompt customization

From ArchWiki
< Talk:Bash
Revision as of 16:29, 11 June 2013 by Karol (talk | contribs) (better delete "Advanced return value visualisation": rm red links)
Jump to navigation Jump to 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)

Using Bold and 256 -Color

  • You can string multiple escape-codes together; This is the only way I could get bold 256-colors to show up on my machine using rxvt-unicode:
 \[\e[(01);(38;5;114)m\]Hello, World
Hello, World

Where (01) is the escape for bold and (38;5;114) is the escape for 256-color #114, which is a slight avocado-green. --Darkhand 15:27, 7 March 2011 (EST)

Wrong cursorposition

After changing all colors from e.g.




my bash stopped missaligning the cursor, clobber old text, and so on.

--Eselfreund 10:17, 6 August 2011 (EDT)


Currently, it is referred from:

    [ -r /etc/bash_completion ] && . /etc/bash_completion

but Arch seems to install the main script in /usr/share/bash-completion/bash_completion --Mloskot (talk) 20:39, 10 June 2012 (UTC)

Step by step

Hello everybody. I wrote the first chapter of this article. I think that the second one (“Step by step”) should be improved and harmonized with the first one... I have already given my contribution ;-) --Martingala (talk) 17:59, 15 November 2012 (UTC)

Copy-Paste Issues

While attempting to implement the bash.bashrc example on my Raspberry Pi using the Midori browser (running Arch), I ran into a strange problem.

When I copy and paste the text for bash.bashrc directly into a text file via nano and do a hexdump, I find the file is littered with strange "c2" and "a0" characters masquerading as spaces.

It caused bash to throw errors and it would not work. After manually replacing these "characters" with a regular 20 space, everything was fine.

I have not tested with any other browser. Hexdump here: It is a hexdump -C | grep c2, and the same with grep a0. So, there's duplicates of problem lines, and the lines which contain a0 in the hex line number, apologies for that. Also see my relevant post on stackexchange:

From a cursory review of the full hexdump, the problem generally occurs before "!=".

Turok (talk) 03:23, 8 June 2013 (UTC)