I only need to set a color that will only effect a particular directory not globally.
If you are using Bash in a terminal that supports colors and would like to change the default color for text output to the terminal (not specifically the output of ls) while inside this directory, there is one thing you could do.
The PROMPT_COMMAND variable can be set to execute a command just before printing the prompt. You could use that to check for the current directory and change the terminal color (for instance by assigning the PS1 variable with a prompt that contains non-displayable special codes for selecting a color or echoing said special codes).
PROMPT_COMMAND is documented in the Bash manual: https://www.gnu.org/software/bash/manual/bashref.html
As for how to assign colors, you should look that up if interested.
This solution may not be what you are looking for, will probably have side effects, and generally speaking, I am not sure it will be that useful changing terminal colors depending on the current directory. The usual solution is to have a prompt that shows the current directory path (or at least the last portion of the path).
I use something similar to the above to change text color depending on which machine I am executing Bash on, as I use ssh a lot from one machine to another over several terminal windows, and color (on a black background) is a good way to remember what machine any given window is connected to.
When I run 'screen' command after logging into the linux terminal from putty,
I see font color of folders got changed.
earlier folders are shown with different color(blue)'
Now all files are in same color.
How can I make sure even screen sessions also use same font settings as original terminal?
There really isn't enough information to answer this question, but here's a couple things you could do to troubleshoot.
Make sure that the $SHELL in screen is the same as the $SHELL in the original terminal (Run echo $SHELL before and after starting screen and compare the results). Perhaps screen is running a different shell and thus not reading your preferred .*rc file.
Also, try starting screen with a specific TERM value. Set screen's term value to $TERM before when starting screen like so:
screen -T $TERM
I would also recommend trying to replace $TERM with xterm if $TERM doesn't solve it.
Do you think there is a way of changing a specific word's color on the Linux terminal or on Putty?
I'm using the "make" command though terminal (and putty sometimes), and I just thought of how nice it would be if among all the warnings, the printed line containing the "error:" would be in red/marked somehow.
It doesn't really matter, because I guess the solution would be somehow terminal recognizing a specific word related, but just for clarafication - I'm compiling a makefile of C/Assembly code.
There is off course the solution of not printing the warnings at all, but I want to see the warnings.
Thanks,
Barak.
See the ANSI terminal escape sequences. Most terminals implement them.
For example, to display a word in red:
The word at the end is in <Esc>[31m red <Esc>[30m .
I have inserted some spaces for clarity, which should be removed.
Unfortunately, this assumes that the foreground color is initially black. If the text is originally white on a black background, this will make subsequent text seem to disappear. (I say seem because it is there and can be viewed by selecting the text.)
This is a very specific issue but, based on what I've seen online, a surprisingly common one. I'm on a rather old version of Scientific Linux 5, which is based on Red Hat. I use vim with the Solarized vim color scheme, and my TERM environment variable is usually set to xterm-256color. This worked fine until I started using tmux. On non-empty lines in vim, the color scheme only extended to the end of the document's characters, the remaining whitespace being plain back background.
The stock fix for this in online guides is to set TERM='screen-256color'. However, upon doing this I would get the ominous warning: WARNING: terminal is not fully functional - (press RETURN), when trying to do innocuous things like read man pages. However, everything seemed to be working fine, and the Solarized bug was fixed.
I've found a functional fix - using TERM='xterm-256color' by default and adding this line to my .bashrc:
alias v='function _vim(){ TERM='screen-256color'; vim $1; TERM='xterm-256color'; };_vim'
but it seems like a hack. Anecdotally, I've also set alias tmux='tmux -2', which is a common suggestion with color-scheme-related issues.
I also know that the terminfo screen-256color is available on my machine.
So, really, the main befuddling thing is that, when using TERM='screen-256color', I'm getting those warnings about full functionality when nothing seems to be wrong.
I don't have root access, so ideally any fix suggestions wouldn't need that.
EDIT: I should mention that TERM='screen-256color-bce' gave the same problems as TERM='screen-256color'.
The user's environment is not specified, but likely using bash and less (Scientific Linux 5 does not have more).
The package list on Scientific Linux 5's ftp site, shows ncurses-5.5-24.20060715.src.rpm, which does not include screen-256color (it was added to ncurses in October 2006). That system might have the later terminal database by some post-install change.
An application using termcap would not see this terminal description. Scientific Linux's bash and less programs could have used termcap rather than terminfo. A quick check of the changelog for bash-3.2-21.el5 says
* Fri Feb 1 2008 Miroslav Lichvar <mlichvar#redhat.com> - 3.2-21
- Link with libtermcap
On some systems, a missing termcap entry will cause a warning. But with Scientific Linux 5, the given warning message comes from less, which checks its terminal description (using the termcap interface), to ensure that it can clear the remainder of the current line, the remainder of the screen and the entire screen.
In Scientific Linux 5, the less package is built with ncurses. A problem with less using TERM=screen-256color would be one of these possibilities
the screen-256color entry is not really installed, or
there is some problem with the termcap interface provided by ncurses.
While there were ongoing performance-fixes for the screen program around this time, the former seems the more likely, as seen in this discussion of a poorly-written entry for screen-256color in early 2006: Re: screen-256color terminfo entry?. What I get from reading this is that there was some poorly-written terminal description (not part of ncurses) which produced the problem. By the time it was proposed for inclusion in ncurses (October 2006), the problem had been repaired. In any case, it would have been corrected at that point.
To recognize better the start and the end of output on a commandline, I want to change the color of my prompt, so that it is visibly different from the programs output. As I use zsh, can anyone give me a hint?
Put this in ~/.zshrc:
autoload -U colors && colors
PS1="%{$fg[red]%}%n%{$reset_color%}#%{$fg[blue]%}%m %{$fg[yellow]%}%~ %{$reset_color%}%% "
Supported Colors:
red, blue, green, cyan, yellow, magenta, black, & white (from this answer) although different computers may have different valid options.
Surround color codes (and any other non-printable chars) with %{....%}. This is for the text wrapping to work correctly.
Additionally, here is how you can get this to work with the directory-trimming from here.
PS1="%{$fg[red]%}%n%{$reset_color%}#%{$fg[blue]%}%m %{$fg[yellow]%}%(5~|%-1~/.../%3~|%4~) %{$reset_color%}%% "
Zsh comes with colored prompts builtin. Try
autoload -U promptinit && promptinit
and then prompt -l lists available prompts, -p fire previews the "fire" prompt, -s fire sets it.
When you are ready to add a prompt add something like this below the autoload line above:
prompt fade red
Here's an example of how to set a red prompt:
PS1=$'\e[0;31m$ \e[0m'
The magic is the \e[0;31m (turn on red foreground) and \e[0m (turn off character attributes). These are called escape sequences. Different escape sequences give you different results, from absolute cursor positioning, to color, to being able to change the title bar of your window, and so on.
For more on escape sequences, see the wikipedia entry on ANSI escape codes
The answer by Bryan Oakley above has a glitch as it has already been pointed out and the solution offered by Andrew Marshall though it does not carry the glitch, nevertheless it does not make it obvious for too much customization on the colors used.
As macOS Catalina asks for zsh to be the default shell from now on, I think several more people may want to customize their prompt and might be coming here for an answer. So, I thought I would try to give a broader summary and touch upon other very closely-related notions that allow more customization.
3-Digit Codes for Various Colors.
First of all, here we can find 3-digit codes for various colors: https://unix.stackexchange.com/a/124409/194343.
For example, 214 is some kind of orange color.
Foreground and Background.
The other key information is that for Foreground and bacKground colors one can define what they want with F and K respectively. Source is zsh manual on visual effects: http://zsh.sourceforge.net/Doc/Release/Prompt-Expansion.html#Visual-effects
So, for example, the following two commands
autoload -U colors && colors
export PS1="%F{214}%K{000}%m%F{015}%K{000}:%F{039}%K{000}%~%F{015}%K{000}\$ "
present the hostname in orange with black background, followed by a colon in white with black background, followed by the current working directory in bright blue with black background, followed by the dollar sign in white with black background.
More related information is found below.
Prompt information on the right-hand side. For example, adding a timestamp. See https://superuser.com/a/1251045/290299. Of course, this can be color-coded, for example with some light blue/purple-ish color, like this:
RPROMPT="%F{111}%K{000}[%D{%f/%m/%y}|%#]"
Colors for ls. After reading the manual for ls, one for example can activate the colors for ls using the following two commands:
export CLICOLOR=1
export LSCOLORS=gafacadabaegedabagacad
Finally, as a last remark that I have not tested as I am happy with my configuration, another avenue might be for someone to install the port coreutils from MacPorts and then use gdircolors (source: https://unix.stackexchange.com/a/174596/194343). (I may edit this last part in the future as all the above are related pieces that make every-day life much more fun and easier to cope with.)
I don't think the autoload -U colors && colors is needed anymore and one can simply do:
PS1="%{%F{red}%}%n%{%f%}#%{%F{blue}%}%m %{%F{yellow}%}%~ %{$%f%}%% "
to achieve the same result as FireDude's answer. See the ZSH documentation for more info.
Try my favorite:
put in
~/.zshrc
this line:
PROMPT='%F{240}%n%F{red}#%F{green}%m:%F{141}%d$ %F{reset}'
don't forget
source ~/.zshrc
to test the changes
you can change the colors/color codes, of course :-)
In order to not waste space in the terminal with special characters to pieces of information, you can differentiate information using multiple colors.
Eg. in order to get this desired effect:
You can do the following to your prompt:
PROMPT='%F{magenta}${PWD/#$HOME/~} %F{green}${vcs_info_msg_0_} %F{cyan}$%F{reset_color} '
The way it works is every time you set a color using $F{myColor} the color from that point onward will stick to that. It's important to add in %{reset_color} at the end so that the input text goes back to the original color (or you could set it to something else if you'd like).
I have found that, with zsh5 (the default one on Debian Jessie), all those solutions works:
$'\e[00m
$fg[white]
$fg{white}
Now, they have a problem: they will move the cursor, resulting in ugly decal when tabbing (for auto-completion). The solution is simply to surround the escape sequences with %{FOOBAR%}. Took me a while to figure this.
For 2nd and 3rd solutions loading colors module is mandatory.
To keep the 1st solution readable, just define variables for the colors you use.
Debian/Ubuntu/Raspberry Pi OS style bash prompt:
autoload -U colors && colors
PS1="%B%F{034}%n#%m%f%b:%B%F{019}%~ %#%f%b "
Not entirely sure if autoload -U colors && colors is necessary but I did need it when I was using $fg[...] instead of %F{...}.
In my example;
%F(%f) starts(stops) foreground color - I've used 256COLOR values but you could also use hex for example, I've used normal green %F{034} but %F{#00aa00} works too
%B(%b) starts(stops) bold
%n $USERNAME
%m short machine name
%~ logged in/working directory with ~ if in home directory
%# display % if normal user or # if su
Edit: Tested on macOS Big Sur, Monterey and Ventura. Unsure of earlier zsh versions but Ventura 13.0 is zsh 5.8.1 (x86_64-apple-darwin22.0)
To get a prompt with the color depending on the last command’s exit status, you could use this:
PS1='%(?.%F{green}.%F{red})%n#%m:%~%# %f'
Just add this line to your ~/.zshrc.
The documentation lists possible placeholders.
To complement all of the above answers another convenient trick is to place the coloured prompt settings into a zsh function. There you may define local variables to alias longer commands, e.g. rc=$reset_color or define your own colour variables. Don't forget to place it into your .zshrc file and call the function you have defined:
# Coloured prompt
autoload -U colors && colors
function myprompt {
local rc=$reset_color
export PS1="%F{cyan}%n%{$rc%}#%F{green}%m%{$rc%}:%F{magenta}%~%{$rc%}%# "
}
myprompt
man zshall and search for PROMPT EXPANSION
After reading the existing answers here, several of them are conflicting. I've tried the various approaches on systems running zsh 4.2 and 5+ and found that the reason these answers are conflicting is that they do not say which version of ZSH they are targeted at. Different versions use different syntax for this and some of them require various autoloads.
So, the best bet is probably to man zshall and search for PROMPT EXPANSION to find out all the rules for your particular installation of zsh. Note in the comments, things like "I use Ubuntu 11.04 or 10.4 or OSX" Are not very meaningful as it's unclear which version of ZSH you are using. Ubuntu 11.04 does not imply a newer version of ZSH than ubuntu 10.04. There may be any number of reasons that an older version was installed. For that matter a newer version of ZSH does not imply which syntax to use without knowing which version of ZSH it is.