Bash Prompt HOWTO: $Revision: 0.100 $, $Date: 2009/08/07 02:33:22 $ | ||
---|---|---|
Prev | Chapter 10. Prompt Code Snippets | Next |
Torben Fjerdingstad wrote to tell me that he often stops jobs and then forgets about them. He uses his prompt to remind himself of backgrounded jobs. Apparently this is fairly popular, because as of Bash 2.04, there is a standard escape sequence for jobs managed by the shell:
[giles@zinfandel]$ export PS1='\W[\j]\$ ' giles[0]$ man ls & [1] 31899 giles[1]$ xman & [2] 31907 [1]+ Stopped man ls giles[2]$ jobs [1]+ Stopped man ls [2]- Running xman & giles[2]$
Note that this shows both stopped and running jobs. To see both, you can use something like the following:
function jobcount { stopped="$(jobs -s | wc -l | tr -d " ")" running="$(jobs -r | wc -l | tr -d " ")" echo -n "${running}r/${stopped}s" }
Using the output of jobcount in a prompt gets results like these:
giles@glo ~[0r/0s]$ xterm & [1] 6589 giles@glo ~[1r/0s]$ man less & [2] 6627 giles@glo ~[2r/0s]$ fg man less [2]+ Stopped man less giles@glo ~[1r/1s]$ jobs [1]- Running xterm & [2]+ Stopped man less giles@glo ~[1r/1s]$ [1]- Done xterm giles@glo ~[0r/1s]$ fg man less giles@glo ~[0r/0s]$
This doesn't always show the stopped job in the prompt that follows immediately after the command is executed - it probably depends on whether the job is launched and put in the background before jobs is run.
There is a known bug in Bash 2.02 that causes the jobs command (a shell builtin) to return nothing to a pipe. If you try the above under Bash 2.02, you will always get a "0" back regardless of how many jobs you have stopped. This problem is fixed in 2.03 and later versions. |
Relative speed: jobs -s | wc -l | sed -e "s/ //g" takes about 0.037 seconds on an unloaded 800MHz Celeron. I expected jobs -s | wc -l | tr -d " " to take less time as tr is a smaller and simpler command, but it took about 0.067 seconds.