Byobu Prompt Now Includes Exit Code of Previous Command and ⟫

Three changes landed in Byobu yesterday, just ahead of Ubuntu 13.10 User Interface Freeze.  These are incremental changes on the work I recently introduced with Byobu's fancy new $PS1 command prompt...

1. The prompt now shows the previous command's exit status, if it's non-zero.  This integer is the $? exit code of the previous command.  I was sitting next to Martin Pitt in New Orleans, at the Linux Plumbers conference and immediately fell in love with this idea.  How many times have we not noticed that the previous command exited non-zero...  Never again!!!
2. The prompt now ends with ⟫ instead of ❭.  I tested every terminal I could get my hands on in Ubuntu, including: gnome-terminal, xterm, uxterm, terminator, konsole.  It turns out that the ⟫ symbol is rendered correctly in more of these (xterm and friends) than ❭.
3. There is also a new keybinding, Alt-F5, which toggles on and off UTF-8 support in the status bar and on the PS1.  The goal here is to provide a fix and an easy escape route when you end up in a terminal that does not properly support UTF-8 out of the box (and Byobu is not able to accurately determine this), like here and here.

Of course, you can always trivially enable and disable Byobu's prompt using:

byobu-enable-prompt

and

byobu-disable-prompt

Cheers,

Dustin

Introducing run-one-constantly, run-one-until-failure and run-one-until-success

Necessity is truly the mother of invention.  I was working from the Isle of Man recently, and really, really enjoyed my stay!  There's no better description for the Isle of Man than "quaint":

quaint
kwānt/
adjective1. attractively unusual or old-fashioned.
"quaint country cottages"

synonyms:

picturesque, charming, sweet, attractive, old-fashioned, old-world

Though that description applies to the Internet connectivity, as well :-)  Truth be told, most hotel WiFi is pretty bad.  But nestle a lovely little old hotel on a forgotten little Viking/Celtic island and you will really see the problem exacerbated.

I worked around most of my downstream issues with a couple of new extensions to the run-one project, and I'm delighted as always to share these with you in Ubuntu's package!

As a reminder, the run-one package already provides:

• run-one COMMAND [ARGS]
• This is a wrapper script that runs no more than one unique instance of some command with a unique set of arguments.
• This is often useful with cronjobs, when you want no more than one copy running at a time.
• run-this-one COMMAND [ARGS]
• This is exactly like run-one, except that it will use pgrep and kill to find and kill any running processes owned by the user and matching the target commands and arguments.
• Note that run-this-one will block while trying to kill matching processes, until all matching processes are dead.
• This is often useful when you want to kill any previous copies of the process you want to run (like VPN, SSL, and SSH tunnels).
• keep-one-running COMMAND [ARGS]
• This command operates exactly like run-one except that it respawns the command with its arguments if it exits for any reason (zero or non-zero).
• This is useful when you want to ensure that you always have a copy of a command or process running, in case it dies or exits for any reason.

Newly added, you can now:

• run-one-constantly COMMAND [ARGS]
• This is simply an alias for keep-one-running.
• I've never liked the fact that this command started with "keep-" instead of "run-one-", from a namespace and discoverability perspective.
• run-one-until-success COMMAND [ARGS]
• This command operates exactly like run-one-constantly except that it respawns "COMMAND [ARGS]" until COMMAND exits successfully (ie, exits zero).
• This is useful when downloading something, perhaps using wget --continue or rsync, over a crappy quaint hotel WiFi connection.
• run-one-until-failure COMMAND [ARGS]
•  This command operates exactly like run-one-constantly except that it respawns "COMMAND [ARGS]" until COMMAND exits with failure (ie, exits non-zero).
• This is useful when you want to run something until something goes wrong.

I am occasionally asked about the difference between these tools and the nohup command...

1. First, the "one" part of run-one-constantly is important, in that it uses run-one to protect you from running more than one instances of the specified command. This is handy for something like an ssh tunnel, that you only really want/need one of.
2. Second, nohup doesn't rerun the specified command if it exits cleanly, or forcibly gets killed. nohup only ignores the hangup signal.

So you might say that the run-one tools are a bit more resilient than nohup.

You can use all of these as of Ubuntu 13.10 (Saucy), by simply:

sudo apt-get install run-one

Or, for older Ubuntu releases:

sudo apt-add-repository ppa:run-one/ppa
sudo apt-get update
sudo apt-get install run-one

I was also asked about the difference between these tools and upstart...

Upstart is Ubuntu's event driven replacement for sysvinit.  It's typically used to start daemons and other scripts, utilities, and "jobs" at boot time.  It has a really cool feature/command/option called respawn, which can be used to provide a very similar effect as run-one-constantly.  In fact, I've used respawn in several of the upstart jobs I've written for the Ubuntu server, so I'm happy to credit upstart's respawn for the idea.

That said, I think the differences between upstart and run-one are certainly different enough to merit both tools, at least on my servers.

1. An upstart job is defined by its own script-like syntax.  You can see many examples in Ubuntu's /etc/init/*.conf.  On my system the average upstart job is 25 lines long.  The run-one commands are simply prepended onto the beginning of any command line program and arguments you want to run.  You can certainly use run-one and friends inside of a script, but they're typically used in an interactive shell command line.
2. An upstart job typically runs at boot time, or when "started" using the start command, and these start jobs located in the root-writable /etc/init/.  Can a non-root user write their own upstart job, and start and stop it?  Not that I can tell (and I'm happy to be corrected here)...    Turns out I was wrong about that, per a set of recently added features to Upstart (thanks, James, and Stuart for pointing out!), non-root users can now write and run their own upstart jobs..   Still, any user on the system can launch run-one jobs, and their own command+arguments namespace is unique to them.
3. run-one is easily usable on systems that do not have upstart available; the only hard dependency is on the flock(1) utility.

Hope that helps!

Happy running,

:-Dustin