And bash basics

16 October 2015   2 comments   Linux, MacOSX

Powered by Fusion×

It's one of those things; not hard to understand and certainly not an advanced trick but I sometimes see people miss out on this.

In bash there are sort of two ways of saying "Do this and then do that". You can either say "Do this and no matter what happens then do that" or you can say "Do this and if that worked also do that".


Suppose you have two command executables you want to run. They can succeed or fail.

$ echo "Do this and no matter what happens then do that"
$ ./command1 ; ./command2

If you run that, ./command2 will run even if ./command1 failed.
The other one is...

$ echo "Do this and if that worked also do that"
$ ./command1 && ./command2

You might recognize the && thing from JavaScript or Java or C or one of those. If you recognize it you might quickly also conclude that you can do this too:

$ echo "Do this and only if it failed do that"
$ ./command1 || ./command2

In this latter case only one of those (or none!) will succeed.

So when does this come in handy?

Here are some examples that I often use:

Meaning, I know my code is good to push, iff the tests pass

$ nosetests && git commit -a -m "some feature" && git push peterbe mybranch

Or if you might want to be alerted if something failed after the first command slowly takes its time to finish:

$ nosetests && say "Tests finished" || say "Work harder"

(say is an OSX specific command and not a built-in in bash)

The ; is useful when you don't care if the first command finished and this is more rare. For example:

$ rm static/ ; ./ collectstatic --noinput

Why bother?

Perhaps it goes without saying, the reason for doing all of these is generally when the first command takes a long time and you don't want to sit and wait till it's finished to run the second time. By "piping them together" like this, the second command will safely start as soon as possible whilst you go away and pay attention to something else.


This is not restricted to bash, as far as I know every shell will behave like this since many, many years, bourne shell based, csh based, zsh, whatever.
Peter Bengtsson
Excellent point. I think saying "bash" has become a lazy synonym for "programming on the *nix command line".
The level of these tips is so "high" that it applies to almost all forms of shells.
Thank you for posting a comment

Your email will never ever be published

Related posts

mozjpeg installation and sample 10 October 2015
How to "onchange" in ReactJS 21 October 2015
Related by Keyword:
A neat trick to zip a git repo with a version number 01 September 2017
set -ex - The most useful bash trick of the year 31 August 2014
How I do deployments 16 December 2013
Bash tip of the day: ff 25 March 2011
pwdf - a mix of ls and pwd 07 April 2008
Related by Text:
Catching a carriage return in bash 23 October 2006
set -ex - The most useful bash trick of the year 31 August 2014
On the command line no one can hear you screen. Or can they? 03 May 2012
How I do deployments 16 December 2013
Read in passwords with bash 25 March 2005