Bash trick: Repeat last command until success

More and more often I come across a scenario where I need to repeat the shell command until it succeeds. Here are a couple of examples:

  • Reboot a server. Try to remotely login to it via ssh. This fails until the server actually boots up. Keep trying until connected.
  • Start an application that writes to the log file. Run “tail -f some.log” to watch the log messages. This fails if the log file does not exist yet. Keep trying until the application creates the log file and writes something into it.

Sure, I can always press the up arrow key and Enter, to repeat the last command from the history. But it is a tiny bit annoying.

Today I came across this little trick, that solves the problem. Add the following function to your .bashrc:

rpt() {
  CMD=$(fc -ln | tail -n 2 | head -n 1)
  echo "repeating until success: $CMD"
  until $CMD
  do
    sleep 1
  done
}

Now you can run “rpt” to repeat the latest command until it succeeds.

Handy!

Falsehoods programmers believe about Unix time

A while back I blogged a collection of “Falsehoods programmers believe about …“. One of those things was time. Today I came across a nice addition to that – “Falsehoods programmers believe about Unix time“.

These three facts all seem eminently sensible and reasonable, right?
1. Unix time is the number of seconds since 1 January 1970 00:00:00 UTC
2. If I wait exactly one second, Unix time advances by exactly one second
3. Unix time can never go backwards
False, false, false.

All three of these are false and for the same reason – leap seconds. The article provides a nice and easy explanation of how and why that happens.

Container misconceptions

Ricard Bejarano points out a few container misconceptions. I particular like the bit about Swarm as a better option than Kubernetes for individual projects and small setups (1-2 nodes):

Swarm is Docker, Inc.’s orchestrator. It started development five years ago. It’s built into the Docker Engine, which makes it the same to run it on development machines as in production servers.
In my opinion, it is much less powerful than Kubernetes, and I would vote against using it in a business environment.
That said, I’m a happy admin of a single-node Swarm running all of my personal services at home. But that’s it. I wouldn’t use it for anything with more than 1-2 nodes, but for those applications, I feel is the right tool for the job.

40x speed up of ls on large dirs

If you ever tried listing a directory with a lot (10,000+) of files in it, I’m sure you know how annoyingly slow ‘ls’ can be. Turns out there is a simple way to make it better. Have a look at the “When setting an environment variable gives you a 40x speedup” blog post.

Or just do the following:

export LS_COLORS='ex=00:su=00:sg=00:ca=00:'

This will disable colors on the executable files, setuid/setgid bits, and capabilities.

Debugging in Vim

Personally, I’m not a frequent user of debuggers. Most of the projects and code that I am involved with is easily debugged with good old “die(‘here’)”. But if you are looking for some help on how to use Vim with a debugger, have a look at the “Debugging in Vim” blog post.