Some of these are pretty cool. One piece of experience I'd like to offer:
Don't ever use ">" in your prompts, particularly as root.
A coworker had spent several days working on* an important script with a tight deadline that was almost upon him, and with a quick slip of the right mouse button, pasted what he had selected before (several lines of window scrollback) into the window to be executed, including:
/tmp/foo> ./blah.pl
and just like that, blah.pl ended up zero length. We hard killed the machine and scanned the disk for the contents of the script and recovered most of it, but had the specifics been different we could have been a lot less lucky.
For this reason it's probably also a good idea to avoid question marks, asterisks, and anything else the shell could expand, as well.
* While the story plays just as well, it's not meant to be an argument for source control. It could have just as easily been full paths to system binaries and have ended up trashing the system.
I'd argue that this isn't really a prompt problem, though.
For example, when using typical Unix terminals, I refuse to mouse copy/paste when logged in as root (whether or not the prompt is nearby), because it's too easy to make a mistake and the consequences are severe. Similarly, I refuse to rely on any cute shell tricks like "!" to pull history items when logged in as root. Sacrifice convenience to guarantee safety.
I also prefer to use my Mac terminal (MacTelnet), which will trap multi-line pastes and offer options to paste as-is, paste as one line, or cancel the operation. This has saved me more than once.
Perhaps the real lesson to be learned here is don't ever login as root (?).
(Certainly there are a few things I don't know about administering large groups of machines. However, I've been running my own personal Linux boxes for a while. And the last time I logged in as root was a bit over 9 years ago.)
path is limited to 30 characters and the front is trimmed with '...'. There is a host, because I work on at least 5 at the same time every day, but the username is cut to only the first 2 letters (so it's either vi, or ro, or something else at uni). The return code is only visible when it's non-zero.
I'd have to rely on zsh being available everywhere:
[rupert] ~$ uname -a
SunOS rupert 5.11 NexentaOS_20081207 i86pc i386 i86pc Solaris
[rupert] ~$ sudo apt-get install zsh
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package zsh is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package zsh has no installation candidate
Seconded. I stuck to bash for a long time, and I regret not changing to zsh much earlier. It's like bash in all the ways bash is good, but with extra excellence thrown in to the bargain.
I especially like the bash history number in the prompt, makes it much easier to use the history effectively. Perhaps if I used jobs rather than tabs I'd throw the job count in there too. But multi-line prompts? that seems a bit excessive.
Hm, I think, that prompt should give you some hint of the environment and context in which the command you are typing will run. Username, working path, machine hostname, at least, of course (well, it isn't really necessary to show hostname, if you never use more than one machine, and so on). On the other hand, I don't like stuff like current time, number of running processes or system load, because they are not part of that context. They are constantly changing, and not only by actions and commands in the shell; when you are done typing and press enter, they won't be valid.
Here's my bash prompt script. It shows the command number from this session (PS_NUM), the exit code of the last command (highlighted red if != 0), the pwd (in cyan), and the git branch (in magenta)
OFF="\[\033[0m\]"
RED="\[\033[0;31m\]"
MAGENTA="\[\033[0;35m\]"
CYAN="\[\033[0;36m\]"
function promptcommand {
STATUS=$?
PS_NUM="[\#]"
PS_STATUS="[$STATUS]"
PS_PWD="${CYAN}\w${OFF}"
PS_GITBRANCH="${MAGENTA}\$(__git_ps1)${OFF}"
PS_PROMPT="\$"
if [ $STATUS -ne "0" ]; then
PS_PROMPT="${RED}${PS_PROMPT}${OFF}"
fi
PS1="${PS_NUM}${PS_STATUS} ${PS_PWD}${PS_GITBRANCH} ${PS_PROMPT} "
}
PROMPT_COMMAND=promptcommand
I probably could have eliminated the PROMPT_COMMAND thing like in the first example.
Reminds me of colorful prompts I used to show off in DOS by device=ansi.sys, (I think - It has been, what, more than 20 years?). Save the current cursor location, go to the top of the screen, show the date, time, working directory (in different colors of course, left, middle and right positions) and then restore the cursor location and show a prompt. In yet more ansi colors.
In a prior life I used zsh and learned to love its show-current-directory-trimmed-to-length prompt code, but these days I've succumbed to inertia and use bash.
With much messing around, I managed to figure out how to replicate the same functionality in bash:
It's interesting that folks are still displaying info in prompts.
With TTYs and their CRT equivalents, there really wasn't any alternative. However, most folks have their command line in a window these days, and windows have other places to put state information.
Don't ever use ">" in your prompts, particularly as root.
A coworker had spent several days working on* an important script with a tight deadline that was almost upon him, and with a quick slip of the right mouse button, pasted what he had selected before (several lines of window scrollback) into the window to be executed, including:
/tmp/foo> ./blah.pl
and just like that, blah.pl ended up zero length. We hard killed the machine and scanned the disk for the contents of the script and recovered most of it, but had the specifics been different we could have been a lot less lucky.
For this reason it's probably also a good idea to avoid question marks, asterisks, and anything else the shell could expand, as well.
* While the story plays just as well, it's not meant to be an argument for source control. It could have just as easily been full paths to system binaries and have ended up trashing the system.