Timeline for How to conditionally do something if a command succeeded or failed
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 4, 2022 at 22:44 | review | Suggested edits | |||
| Apr 5, 2022 at 11:40 | |||||
| Jan 10, 2022 at 16:38 | comment | added | Feline | unnecessary complexity | |
| Jan 7, 2022 at 15:41 | comment | added | glenn jackman | If the command is long, it can be put into an array: cmd=( theCommand "with args" and "other args" "and so on"); if "${cmd[@]}"; then ... -- I expecially like this because the array definition can include arbitrary whitespace so the options can be laid out with newlines for maximum readability. | |
| Jun 18, 2021 at 7:10 | comment | added | Timo | Info on the result values with $? | |
| Jan 8, 2021 at 11:05 | comment | added | yurez | @spikyjt You can capture the output and fail on error by using if ! output=$(command); then ... syntax. | |
| Mar 3, 2020 at 13:47 | comment | added | spikyjt | This pattern can be useful, when you want to capture the output of a command into a variable, but also fail on error, e.g. result=$(command); if [ $? -eq 0 ]; then .... The gotcha here though is that if you declare, local or readonly the var that you are assigning, then $? will be the return value of the assignment command, not the command that you are interested in! (So declare the var first, then assign it). | |
| Sep 16, 2019 at 1:34 | comment | added | Nikhil VJ | I prefer this for readability. The main command is typically a really long one. Putting it inside an "if" statement makes for bad readability. | |
| Aug 19, 2019 at 17:34 | comment | added | Sz. | @triplee, "if ! cmd is fine" ah thanks! (I did try, but I managed to get something obvious wrong then. I guess I only tried a not, instead of just a !.) | |
| Aug 19, 2019 at 17:13 | comment | added | tripleee | @lunakid If you don't care about the exit code, if ! cmd is fine. Otherwise, a common arrangement is to use an else clause. You can't have an empty then but you sometimes see then : nothing; else where the : no-op is significant. true would work there as well. | |
| Aug 19, 2019 at 15:51 | comment | added | Sz. | @triplee: And how do you go about acting on the negated exit status (i.e. on failure) with if? If the success branch is a no-op, so you'd only need if ! cmd; then error..., as I understand, if alone can't do the negation (bash doesn't seem to have a not builtin), so one should resort to some [ ... ] hackery then, right? | |
| Apr 17, 2018 at 9:23 | comment | added | tripleee | @danfromisrael Most of the other answers on this page; Keith's in paricular. | |
| Apr 17, 2018 at 9:02 | comment | added | danfromisrael | @triplee so what is the correct pattern ? | |
| Nov 4, 2016 at 12:34 | comment | added | tripleee | @Nowaker The fact that the sole purpose of if is to do this. The flow control conditions in Bash all examine $? behind the scenes; that's what they do. Explicitly examining its value should be unnecessary in the vast majority of cases, and is usually a beginner antipattern. | |
| Jun 27, 2016 at 1:37 | comment | added | Nowaker | What is "Bash's if idiom"? | |
| Oct 7, 2015 at 21:16 | comment | added | taxilian | There are benefits to this idiom -- it preserves the return value. In all, I find this one to be more powerful, though more verbose. it's also easier to read. | |
| Oct 17, 2011 at 11:30 | comment | added | janmoesen | While technically correct (and thus not warranting a downvote), it's not making use of Bash's if idiom. I prefer Keith Thompson's answer. | |
| Oct 16, 2011 at 22:29 | history | migrated | from programmers.stackexchange.com (revisions) | ||
| Oct 16, 2011 at 21:34 | history | answered | Ryan Stewart | CC BY-SA 3.0 |