According to the ZSH manual, for ZSH V5.1+ colors should be able to be defined as a # followed by an RGB color code as a hexadecimal triplet, for eg. #ff00ff. However, I have found no documentation that provides a concrete example to demonstrate how exactly this is achieved, and no matter how I try to define a color variable, it never seems to produce the color I want (or any color for that matter). I have tried all of the following formats and none have worked so far when I attempt to use them in %F or %K in the prompt definition (eg. PS1="%F{$var} >> %f")
var=#ff00ff
var="#ff00ff"
var='#ff00ff'
var=$"#ff00ff"
var=$'#ff00ff'
I am running the shell in the kitty terminal emulator, which has truecolor support enabled by default.
All 255 color numbers (eg. var=231) in zsh work just fine, color names (eg. yellow) as well.
I am currently running ZSH V5.5.1.
I have looked for information on the zsh manual page [] and so far nohing more than a mention about it is provided.
I'm looking for an example of how to define hex code colors (and assign them to variables) in no uncertain terms.
After some more experimentation, I determined that the problem was partly the documentation, and partly the version. In essence, to declare hex triples in zsh you use the format var='#f0f0f0'. For this to work it is required that you have ZSH V5.7+, despite what the documentation may say about it working in ZSH V5.1+
I hope this answer will be helpful to anybody else who encounters this difficulty.
My NodeJS console.log() function no longer displays Strings correctly in Window's cmd. They render as black text with a black background. I don't remember changing anything that could have lead to this.
I'm pretty sure it's the colors, though not the ones of the terminal itself (I've tried changing those), since when I copy the text, it has the correct output. I've included a screenshot of how it looks.
Screenshot:
Text output:
{ key1: 'value',
key2: 51,
key3: 2019-05-31T08:05:51.492Z,
key4: [ '12', '23', '24' ] }
Has anyone else had the same problem? What could have caused this (wasn't always like this).
EDIT: From what I gathered, the Object.toString method is causing the objects to display incorrectly. Node tells me it is native code though. What could be causing this issue?
Looks like maybe somebody monkey-patched console.log and used something like https://www.npmjs.com/package/cli-highlight to color the output before it is written.
I'd ask around in your team and search for commits mentioning console in your source code repository.
If you can, check the behavior on a different environment, to learn whether it's something specific to your machine, like your terminal configuration.
So I figure it out. Something (I don't know what, I doubt I did that accidentally) changed a few of the cmd colors in the registry, causing them to be black. I don't know what could have caused this, but it works now at least. If you ever stumble upon the same problem, look up the color values at HKEY_CURRENT_USER\Console and look if some of the Color table values may be se to zero. I was able to find some values of another user, and while they weren't exactly the ones it was originally set to, they fixed it.
The make files generated by CMake have a colorful output for improved readability.
Is it possible to change the color? I have a green terminal font so I kind of loose the color for the messages indicating that objects are built.
I assume you are talking about the cmake added messages from the make output (and not the normal make output itself) in which case it looks like those lines are hard-coded into the generated makefiles with arguments to the cmake cmake_echo_color command that include literal color names as arguments. So there don't appear to be any variables to override or anything of the sort that would let you change that.
So, no, it looks like you cannot control the colors that cmake uses for its various messages. At all.
It doesn't even get the values it uses to control the colors from your terminal's termcap/terminfo it has hard-coded escape sequences in the source code from what I can tell.
The only think you can do is change your terminal's color definitions.
Edit:
While discussing this with a colleague we came up with a fairly obvious and unsophisticated workaround for this. Create a cmake wrapper script, assign the path to it to the $(CMAKE) variable (the only variable in use on that generated make line) and then your wrapper needs to scan for the -E cmake_echo_color command sequence and replace whatever color the command was going to be using with the appropriate argument for the color you want to use.
The only problem with this approach is that there is nothing in the command line that indicates any category or any of the sort other than the message itself so to do this in anything resembling a coherent fashion is going to require a filtering on (potentially random) message texts.
As of 2022, it still isn't possible to change the colors.
I've filed two bugs about this with Kitware:
https://gitlab.kitware.com/cmake/cmake/-/issues/23277
https://gitlab.kitware.com/cmake/cmake/-/issues/23279
So maybe things will improve like they have for ccmake.
Warning: you know how they say "there's not such thing as a stupid question"? Well, this one is, or, I suspect it's really minor, but wth, why not ask. Search engines didn't bring me anything remotely useful, though that could be bad searchterm-fu.
I recently downloaded sqlite3 onto Ubuntu 10 to start learning SQL commands. I un-tar'd 3.7.12.01 and make installed.
After creating a test.db with create table test (id) I decided to see what I'd get if I cat it. Just because.
The result is an EOT character (u+0004) which is sitting right over my prompt. Illustrated screenshot: http://imgur.com/omfMa
I realise this is not the type of file you would use cat on. I only want to know, before I go further,
does the strange placement of this character signal any future issues when actually playing around with SQL, or some issue with newlines, or fonts (this is monofur set at a high font size) or similar?
I've never seen a result character placed directly over my prompt before.
The character is placed over your prompt, because it is a double-width character, and terminals in general are not good at handling double-width characters. It does not mean anything.
There are some control codes which can do very funny things with your terminal, such as changing colors, fonts etc.
But none of them do really harm - you should be able to reset your terminal to a healthy state, or close it and open a new one.
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.