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

From ArchWiki
Jump to: navigation, search
(Interactive statement seems unneeded.)
m (Reorganization: closing)
 
(41 intermediate revisions by 14 users not shown)
Line 1: Line 1:
== Return in non interactive mode ==
+
== <s>Reorganization</s> ==
{{bc|<nowiki>
+
# 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
+
This article is a mess. I suggest a complete reorganization into two sections:
# past this point for scp and rcp, and it's important to refrain from
+
# a section covering the various techniques for colorizing the prompt e.g. tput, escape codes, PROMPT_COMMAND, etc.
# outputting anything in those cases.
+
# a section containing many ''small'', useful examples
  
# If not running interactively, don't do anything!
+
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.  
[[ $- != *i* ]] && return
+
</nowiki>}}
+
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 ==
+
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.
  
The return value visualization stuff didn't quite work right for me.
+
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.
The command history prints out funny (bits of old command prefixes
+
[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 22:16, 3 February 2016 (UTC)
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
+
: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)
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
+
::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)
    # 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 $?.
+
    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
+
:::Makes sense to me. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 13:46, 5 February 2016 (UTC)
following failing commands in bright green with the exit code shown.
+
  
&mdash; Preceding unsigned comment added by [[User:Bkerin|Bkerin]]
+
::::All seems to be done, closing. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:10, 4 June 2016 (UTC)
 
+
 
+
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>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>.
+
These symbols does not work with text terminal. To fix this, replace first 2 lines with this:
+
    if [ "$TERM" = "linux" ]
+
    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.
+
 
+
&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)
+
 
+
 
+
https://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 <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/:
+
{{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)
+
 
+
== 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 09:10, 4 June 2016

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)
All seems to be done, closing. -- Lahwaacz (talk) 09:10, 4 June 2016 (UTC)