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

From ArchWiki
Jump to: navigation, search
(Step by step)
m (Silverhammermba moved page Talk:Color Bash Prompt to Talk:Bash/Prompt customization: article is now about much more than just coloring the prompt)
 
(45 intermediate revisions by 16 users not shown)
Line 1: Line 1:
== Return value visualization ==
+
== <s>Question: Why not promoting the use of tput ?</s> ==
 +
It happens that escape sequence behave differently from one terminal to another...
 +
tput should be used to determine the exact color code for the terminal it is running in !
 +
[http://wiki.bash-hackers.org/scripting/terminalcodes]
  
The return value visualization stuff didn't quite work right for me.
+
{{Unsigned|22:35, 2014 January 19‎|Netmonk}}
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
+
: For simple stuff tput is handy, but unfortunately the terminfo databases tend to be incomplete. For example, the official (latest) 9.20 rxvt-unicode terminfo file still lacks "SGR 22 → Normal (neither bold nor faint)". Some distros (kernel 3.10.32) still ship rxvt-unicode terminfo files without sitm (italic) mode. So sometimes directly using standardized & ubiquitous SGR (xterm & derivatives ie rxvt, vt100 & derivatives ie sakura/gnome-terminal, screen, tmux, etc) escape codes (http://invisible-island.net/xterm/ctlseqs/ctlseqs.html) is simpler, and also sufficiently cross-compatible.
with one echo then putting out the characters to reset the font
+
:{{Unsigned|22:20, 2014 June 6‎|Orbisvicis}}
elsewhere. I asked on the bash list and ended up doing this:
+
  
    # Make the prompt dark red when the previous command has succeeded, or
+
::I kind of agree with both of you. After doing some research, tput does seem to be the more proper/portable way to input escape codes. Missing terminfo entries can be due to an incorrect {{ic|TERM}} setting, which is a pretty common mistake for users. For example, I just noticed my TERM is set to xterm, even though it supports 256 colors. I have to manually set it to xterm-256color in order for {{ic|tput setaf}} to work outside the 0-9 range.
    # bright green when it has failed (in keeping with the slightly backwards
+
::That being said, I would argue that something like {{ic|tput sgr0}} is only ''marginally'' more readable than {{ic|\e[0m}} and it can be pretty tricky to figure out the right tput command in certain situations, even when the terminfo entry exists. So if you know the escape sequence and it definitely works in your shell, it is certainly acceptable to use it. I think with my latest edits to the article, we can close this discussion.
    # way exit codes work :).
+
::[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 16:21, 5 February 2016 (UTC)
    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 $?.
+
    PROMPT_COMMAND='MYPROMPT_LUCES=$?' 
+
    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
+
== <s>Show battery level on bash prompt for laptops</s> ==
following failing commands in bright green with the exit code shown.
+
  
&mdash; Preceding unsigned comment added by [[User:Bkerin|Bkerin]]
+
I just noticed two things :
 +
The link to the post in section 5.2 is dead, so maybe it should be moved/edited?
 +
And also the article to which it refers is very outdated, and the script needs editing due to the fact that battery level and state are no longer found in /proc/acpi/battery/BAT0/ but in /sys/class/power_supply/BAT0/. What exactly should be done about that? I have edited the script to make it work on my computer (http://pastebin.com/6QNVKgPZ), but I don't know if it works everywhere. Should we just warn people? Take it out? Leave it as is and let poeple do their own editing to fit the new system? Sorry I'm a bit long but this is my first time editing so I don't know what should be done...
 +
Thanks for your thoughts/suggestions! [[User:Sparrowhawk|Sparrowhawk]] ([[User talk:Sparrowhawk|talk]]) 15:38, 10 May 2014 (UTC)
  
 +
:Hey, the article is now totally different, so I'm going to go ahead and close this discussion topic. To address your original question, a combination of [[ACPI modules#Getting information]] and [[Color Bash Prompt#Embedding commands]] should make it clear how to achieve what you want. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 05:21, 6 February 2016 (UTC)
  
There is another, very simple method to get it work without problems with breaking lines.
+
== Reorganization ==
Rename PS1 to _PS1 in .bashrc and add this lines after _PS1 variable:
+
    <nowiki>RET_SUCC="\[\033[32;1m\]\342\234\223"</nowiki>
+
    <nowiki>RET_FAIL="\[\033[31;1m\]\342\234\227"</nowiki>
+
    <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>.
+
This article is a mess. I suggest a complete reorganization into two sections:
These symbols does not work with text terminal. To fix this, replace first 2 lines with this:
+
# a section covering the various techniques for colorizing the prompt e.g. tput, escape codes, PROMPT_COMMAND, etc.
    if [ "$TERM" = "linux" ]
+
# a section containing many ''small'', useful examples
    then
+
      RET_SUCC="\[\033[32;1m\]v"
+
      RET_FAIL="\[\033[31;1m\]x"
+
    else
+
      RET_SUCC="\[\033[32;1m\]\342\234\223"
+
      RET_FAIL="\[\033[31;1m\]\342\234\227"
+
    fi
+
  
This is only an example, it is possible to add anything that PS1 accepts using this method.
+
Right now the various prompt-manipulation techniques are scattered throughout the article, making it difficult for users who are trying to create some custom effect. Also it has many lengthy and/or confusing scripts which are susceptible to bit rot and blind copy-pasting by unwary users.  
  
&mdash; Preceding unsigned comment added by [[User:Noctivivans|Noctivivans]]
+
Example scripts have their place on the wiki, but tailored solutions for lazy users to mindlessly copy-paste is not it. If the script isn't reasonably simple and general enough for the average Arch user to reasonably understand and adapt to their own system, it might as well not be here. I would much rather have a more technical article that explains the ''methods behind the scripts'' and leaves out the scripts themselves.
  
== Examples ==
+
I also have a nagging feeling that this whole mess is off topic as not being Arch-specific enough. Perhaps giving it a more technical bent would help with that.
 +
[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 22:16, 3 February 2016 (UTC)
  
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 do agree we should emphasize on the methods, rather than randomly convoluted examples. +1 -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:17, 4 February 2016 (UTC)
  
: 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)
+
::With Silverhammermba's recent edits, I'll suggest to move this page to [[bash/Prompt customization]] and merge with [[bash#Prompt customization]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:44, 5 February 2016 (UTC)
  
::Very nice, indeed!  Thank you very much.  This will help immensely.
+
:::Makes sense to me. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 13:46, 5 February 2016 (UTC)
 
+
::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)
+
 
+
 
+
http://wiki.archlinux.org/index.php?title=Color_Bash_Prompt&diff=107296&oldid=prev
+
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 [[ $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 http://www.ibm.com/developerworks/linux/library/l-tip-prompt/:
+
{{bc|
+
...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
+
 
+
{{bc|1=
+
<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.
+
 
+
    \e[1;30m 
+
to
+
    \[\e[1;30m\]
+
 
+
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)
+

Latest revision as of 05:23, 6 February 2016

Question: Why not promoting the use of tput ?

It happens that escape sequence behave differently from one terminal to another... tput should be used to determine the exact color code for the terminal it is running in ! [1]

—This unsigned comment is by Netmonk (talk) 22:35, 2014 January 19‎. Please sign your posts with ~~~~!

For simple stuff tput is handy, but unfortunately the terminfo databases tend to be incomplete. For example, the official (latest) 9.20 rxvt-unicode terminfo file still lacks "SGR 22 → Normal (neither bold nor faint)". Some distros (kernel 3.10.32) still ship rxvt-unicode terminfo files without sitm (italic) mode. So sometimes directly using standardized & ubiquitous SGR (xterm & derivatives ie rxvt, vt100 & derivatives ie sakura/gnome-terminal, screen, tmux, etc) escape codes (http://invisible-island.net/xterm/ctlseqs/ctlseqs.html) is simpler, and also sufficiently cross-compatible.
—This unsigned comment is by Orbisvicis (talk) 22:20, 2014 June 6‎. Please sign your posts with ~~~~!
I kind of agree with both of you. After doing some research, tput does seem to be the more proper/portable way to input escape codes. Missing terminfo entries can be due to an incorrect TERM setting, which is a pretty common mistake for users. For example, I just noticed my TERM is set to xterm, even though it supports 256 colors. I have to manually set it to xterm-256color in order for tput setaf to work outside the 0-9 range.
That being said, I would argue that something like tput sgr0 is only marginally more readable than \e[0m and it can be pretty tricky to figure out the right tput command in certain situations, even when the terminfo entry exists. So if you know the escape sequence and it definitely works in your shell, it is certainly acceptable to use it. I think with my latest edits to the article, we can close this discussion.
Silverhammermba (talk) 16:21, 5 February 2016 (UTC)

Show battery level on bash prompt for laptops

I just noticed two things : The link to the post in section 5.2 is dead, so maybe it should be moved/edited? And also the article to which it refers is very outdated, and the script needs editing due to the fact that battery level and state are no longer found in /proc/acpi/battery/BAT0/ but in /sys/class/power_supply/BAT0/. What exactly should be done about that? I have edited the script to make it work on my computer (http://pastebin.com/6QNVKgPZ), but I don't know if it works everywhere. Should we just warn people? Take it out? Leave it as is and let poeple do their own editing to fit the new system? Sorry I'm a bit long but this is my first time editing so I don't know what should be done... Thanks for your thoughts/suggestions! Sparrowhawk (talk) 15:38, 10 May 2014 (UTC)

Hey, the article is now totally different, so I'm going to go ahead and close this discussion topic. To address your original question, a combination of ACPI modules#Getting information and Color Bash Prompt#Embedding commands should make it clear how to achieve what you want. Silverhammermba (talk) 05:21, 6 February 2016 (UTC)

Reorganization

This article is a mess. I suggest a complete reorganization into two sections:

  1. a section covering the various techniques for colorizing the prompt e.g. tput, escape codes, PROMPT_COMMAND, etc.
  2. a section containing many small, useful examples

Right now the various prompt-manipulation techniques are scattered throughout the article, making it difficult for users who are trying to create some custom effect. Also it has many lengthy and/or confusing scripts which are susceptible to bit rot and blind copy-pasting by unwary users.

Example scripts have their place on the wiki, but tailored solutions for lazy users to mindlessly copy-paste is not it. If the script isn't reasonably simple and general enough for the average Arch user to reasonably understand and adapt to their own system, it might as well not be here. I would much rather have a more technical article that explains the methods behind the scripts and leaves out the scripts themselves.

I also have a nagging feeling that this whole mess is off topic as not being Arch-specific enough. Perhaps giving it a more technical bent would help with that. Silverhammermba (talk) 22:16, 3 February 2016 (UTC)

I do agree we should emphasize on the methods, rather than randomly convoluted examples. +1 -- Alad (talk) 13:17, 4 February 2016 (UTC)
With Silverhammermba's recent edits, I'll suggest to move this page to bash/Prompt customization and merge with bash#Prompt customization. -- Lahwaacz (talk) 13:44, 5 February 2016 (UTC)
Makes sense to me. Silverhammermba (talk) 13:46, 5 February 2016 (UTC)