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".
Examples
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/ ; ./manage.py 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.
Comments
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.
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.