Difference between revisions of "Talk:Bash/Prompt customization"

From ArchWiki
Jump to: navigation, search
(Interactive statement seems unneeded.)
m (Reorganization: remove closed discussion)
(42 intermediate revisions by 14 users not shown)
Line 1: Line 1:
== Return in non interactive mode ==
# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output. So make sure this doesn't display
# anything or bad things will happen !
# Test for an interactive shell. There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
# If not running interactively, don't do anything!
[[ $- != *i* ]] && return
Some Linux distributions like ArchLinux actually distribute a bashrc with a statement like {{ic|<nowiki>[[ $- != *i* ]] && return</nowiki>}} included (see above). The comments say the bashrc script has to exit (return) because tools like scp are running in interactive mode and don't support having some user customizations, this is the reason why we have to return. But the return code actually returns if the script isn't run in interactive mode ({{ic|1=!= *i*}}), which is the contrary of what we want to achieve. Can anyone explain me that? Either the comments are incorrect or it is unneeded to use that return statement. But on IRC, some people agreed with me regarding this problem. And on the {{ic|#bash}} channel, some said the statement is unneeded because all scripts (which are all running in non-interactive mode) do not source ANY configuration files like {{ic|/etc/profile}} and {{ic|bashrc}} file. [[User:Wget|Wget]] ([[User talk:Wget|talk]]) 20:18, 25 August 2013 (UTC)
== 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.
&mdash; Preceding unsigned comment added by [[User:Bkerin|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:
    <nowiki>PROMPT_COMMAND='RET=$?; if [[ $RET -eq 0 ]]; then export PS1="${RET_SUCC} ${_PS1}"; else export PS1="${RET_FAIL} ${_PS1}"; fi'</nowiki>
In this example RET_SUCC is <font color="green">✓</font>, and RET_FAIL is <font color="red">✗</font>.
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.
&mdash; Preceding unsigned comment added by [[User:Noctivivans|Noctivivans]]
== Examples ==
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. - [[User:KitchM|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! --[[User:DJPohly|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 <u>before</u> they start changing things.  I will dive right in.  I love "zero defects" methods.
::Thanks again.  Keep up the great work. - [[User:KitchM|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.
[[User:Karol|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 <nowiki>[[ $RET = 0 ]]</nowiki>; 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 <nowiki>[[ $RET = 0 ]]</nowiki>; 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 http://www.ibm.com/developerworks/linux/library/l-tip-prompt/:
...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. ...
--[[User:Nikel|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.  -- [[User:DJPohly|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
<span style="color: #87d787;font-weight:Bold">Hello, World</span>
Where (01) is the escape for bold and (38;5;114) is the escape for 256-color #114, which is a slight avocado-green.
--[[User:Darkhand|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.
--[[User:Eselfreund|Eselfreund]] 10:17, 6 August 2011 (EDT)
== bash_completion ==
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 --[[User:Mloskot|Mloskot]] ([[User talk:Mloskot|talk]]) 20:39, 10 June 2012 (UTC)
== Step by step ==
Hello everybody.
I wrote [[Color_Bash_Prompt#A_well-established_Bash_color_prompt|the first chapter]] of this article. I think that [[Color_Bash_Prompt#Step_by_step|the second one (“Step by step”)]] should be improved and harmonized with the first one... I have already given my contribution ;-) --[[User:Martingala|Martingala]] ([[User talk: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: http://fpaste.org/17386/. 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: http://unix.stackexchange.com/questions/78658/etc-bash-bashrc-errors.
From a cursory review of the full hexdump, the problem generally occurs before "!=".
[[User:Turok|Turok]] ([[User talk:Turok|talk]]) 03:23, 8 June 2013 (UTC)

Latest revision as of 10:18, 11 April 2017