106

This question already has an answer here:

What is the difference between the following methods of chaining commands?

cmd1; cmd2
cmd1 && cmd2

marked as duplicate by G-Man, Archemar, countermode, Toby Speight, Kusalananda Jan 11 '17 at 11:00

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • I hate when I have to choose between two good answers :-) – varesa Apr 22 '12 at 19:28
146

Assume there is command1 && command2.

In this case command2 will be executed if and only if command1 returned zero exit status.

; is just a command separator. Thus command2 will be executed whatever command1 returned.

$> [[ "a" = "b" ]] && echo ok 

$> [[ "a" = "b" ]]; echo ok 
ok
  • 29
    Similarly, command1 || command2 can be used to run command2 only if command1 returned a nonzero exit status. – hammar Apr 22 '12 at 20:19
  • 4
    Note that the return value of the full expression is the return value of the last command that was executed. – Stéphane Gimenez Apr 22 '12 at 22:05
  • 2
    Weird actually.. if command1 returns zero, then command2 is executed? Thinking about lazy evaluation, an && should not even look at the second argument when the first is already 0 - the result will be 0 anyway. – Konerak Apr 24 '12 at 8:57
  • 6
    @Konerak: With exit codes, 0 indicates success, or true while anything else is false, so it's sort of reversed compared to "ordinary" booleans. – hammar Apr 27 '12 at 20:25
  • @hammar that seems rather unfortunate. A more logical choice would be 0 || next_step to indicate success of the previous step, in line with lazy evaluation of logical or. – John Jiang Oct 17 '17 at 17:28
32

cmd1; cmd2 executes cmd1, then cmd2, no matter what. It it exactly equivalent to putting cmd1 and cmd2 on separate lines¹. The return status of this compound command is that of cmd2.

cmd1 && cmd2 executes cmd1. Then, if the exit status of cmd1 is zero, cmd2 is executed. The return status of this compound command is that of cmd1 if it is nonzero (so cmd2 didn't run), and that of cmd2 otherwise (if it ran).

if cmd1; then cmd2; fi is mostly equivalent to cmd1 && cmd2. The main difference is that the version with if returns 0 if cmd1 returns a nonzero status.

A command returns 0 to indicate success, and a nonzero error code (between 1 and 255, usually between 1 and 125 as higher values have other meanings) to indicate failure. Thus cmd1; cmd2 means “execute these commands in sequence no matter what”, whereas cmd1 && cmd2 means “execute these commands, but stop immediately if the first command fails”.

You can tell the shell to enter “exit on error” mode by running set -e. In this mode, the shell exits as soon as any command returns a nonzero status, except in conditional constructs (the left side of && or ||, the condition part of if and while). Thus, under set -e, ; (or a newline) is effectively equivalent to &&².

¹ In terms on control flow, that is. Newlines and semicolons are executed in exactly the same way, but they aren't parsed in exactly the same way, so e.g. alias ls=true; ls executes ls and not true because the parser performs alias resolution on ls before it executes the alias definition.
¹ This isn't to say you can blindly replace && by ; if you've added set -e. For example, ; has lower precedence than &&, so cmd1 && cmd2 || cmd3 is equivalent to set -e; { cmd1; cmd2; } || cmd3. Also, set -e interacts badly with subshells — the details would derail this answer too far.

  • "as higher values have other meanings" what do they mean? If I'm writing my own program, is there any standard error naming (numbering?) convention? – rahmu Apr 23 '12 at 9:42
  • 3
    @rahmu Shells use error codes 126 and 127 to indicate that the program could not be started at all, and 128+N to indicate that the program died with signal N. So from a shell, the only status codes that unambiguously show that the program ran to completion are 0 to 126 (and 128, if you really want to confuse readers). – Gilles Apr 23 '12 at 17:02
  • @Gilles: I don't fully agree with the last sentence. Try echo $(set -e; { false; (exit 2) } && true; echo $?) vs echo $(set -e; { false && (exit 2) } && true; echo $?) ;) – Stéphane Gimenez Apr 23 '12 at 18:59
  • @StéphaneGimenez Ok, yes, set -e and subshells together can be funky. – Gilles Apr 23 '12 at 20:02
  • Note: cmd1; cmd2 is not necessarily the same as cmd1<newline>cmd2. Cases that come to mind are when cmd1 affects the shell parsing like alias commands or commands that change the localisation settings. For instance, alias foo=bar;foo is not necessarily the same as alias foo=bar<newline>foo. – Stéphane Chazelas Jan 11 '17 at 10:26
21

The first line will execute one command after another, irrespective of whether the first one succeeded or not. The second line is an example of shell logic: it will only execute the second command if the first one succeeded. This is because && is logical and. Therefore, if the first command fails, the logical state of the entire line is known to be false and there is no need to evaluate the second command.

3

More practical, there's a difference between

cd /backup/old; rm -rf -- *

and

cd /backup/old && rm -rf -- *

. Besides it's a stupid way, the first one will remove your whole filesystem (or $HOME, depending how it's called) because it runs rm regardless of whether the cd succeeded or not.

  • 14
    While your answer is correct, it's dangerous if a user ran it to see the difference for himself. Why not "echo something" instead? – Randy Stegbauer Apr 23 '12 at 17:46
  • 3
    I trust people not to do obviously stupid things. This is a +/- example I heard first hand. – Reactormonk Apr 23 '12 at 22:56
  • 2
    @RandyStegbauer Because people who will run this do not deserve to have files in their filesystem. – alexg Oct 15 '14 at 8:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.