Elegant Bash Conditionals(timvisee.com)
timvisee.com
Elegant Bash Conditionals
https://timvisee.com/blog/elegant-bash-conditionals/
94 comments
"test" and its alias "[" are actually builtins:
https://www.gnu.org/software/bash/manual/html_node/Bourne-Sh...
They also exist as executables for ancient backwards compatibility.
"[[" is a so-called "conditional construct":
https://www.gnu.org/software/bash/manual/html_node/Condition...
I have a somewhat quirky style and almost always use "if test ..." since I find it clearer than "[" and usually don't need the additional functionality that "[[" provides.
https://www.gnu.org/software/bash/manual/html_node/Bourne-Sh...
They also exist as executables for ancient backwards compatibility.
"[[" is a so-called "conditional construct":
https://www.gnu.org/software/bash/manual/html_node/Condition...
I have a somewhat quirky style and almost always use "if test ..." since I find it clearer than "[" and usually don't need the additional functionality that "[[" provides.
I always use "test" and never "[" (and I've only used "[[" once when I thought I needed a builtin regex matcher for efficiency). Partly because fish does the same, partly because despite writing bash scripts for years I do not want to have the "[ vs [[" information in my brain (nor should whoever reads my code).
(For similar reasons, whenever I'm grepping for a nontrivial regex, I always use egrep rather than grep, because the escaping semantics are simpler—"if it's escaped with a \, then it's not special"—and again I do not want to have the information of "which characters are special only when escaped in base grep" in my brain.)
(For similar reasons, whenever I'm grepping for a nontrivial regex, I always use egrep rather than grep, because the escaping semantics are simpler—"if it's escaped with a \, then it's not special"—and again I do not want to have the information of "which characters are special only when escaped in base grep" in my brain.)
> I do not want to have the information of "which characters are special only when escaped in base grep" in my brain
Tangential but relevant to the Edit thread today were vis was mentioned, “No more {very-,}{no,}magic modes with different semantics and escaping rules. Instead we use the familiar and predictable POSIX Extended Regular Expression variant.”¹ is a real advantage over vim.
¹https://github.com/martanne/vis/wiki/Differences-from-Vi(m)#...
Tangential but relevant to the Edit thread today were vis was mentioned, “No more {very-,}{no,}magic modes with different semantics and escaping rules. Instead we use the familiar and predictable POSIX Extended Regular Expression variant.”¹ is a real advantage over vim.
¹https://github.com/martanne/vis/wiki/Differences-from-Vi(m)#...
$ type -a [
[ is a shell builtin
[ is /usr/bin/[
$ type -a [[
[[ is a shell keywordYou can be clever in personal files, say ~/.bash_profile — for your user personally.
But never in scripts used in production that must be maintained by a group.
That rule served me well for many years. YMMV
But never in scripts used in production that must be maintained by a group.
That rule served me well for many years. YMMV
Couldn't agree more.
As a very occasional bash script user (who'll go with Python instead whenever possible) I sort of lost interest already at the first, banale example:
>>if [ -r ~/.profile ]; then
>> source ~/.profile
>>fi
>>We can simplify this using control operators:
>>[ -r ~/.profile ] && . ~/.profile
I wonder which version I would prefer for readability three months down the road.
>>if [ -r ~/.profile ]; then
>> source ~/.profile
>>fi
>>We can simplify this using control operators:
>>[ -r ~/.profile ] && . ~/.profile
I wonder which version I would prefer for readability three months down the road.
Hopefully people wouldn't give up at that and instead search something like "bash syntax" and find the manual :
https://www.gnu.org/software/bash/manual/bash.html#Bash-Cond...
https://www.gnu.org/software/bash/manual/bash.html#Bash-Cond...
The one that usually gets me is built-ins shadowing binaries, such that `man time` doesn't actually give me the info I need.
I had this problem as well until I learned to use `type time`, to help me decide whether I need `man time` or `help time` (documenting the built-in)
'[' is a Bash builtin. See https://www.computerhope.com/unix/bash/index.htm.
It is usually also a symlink to the 'test' executable but not in all Unix-like systems.
It is usually also a symlink to the 'test' executable but not in all Unix-like systems.
One of the most useful tricks I've learned and now apply to every non-throwaway shell script is the use of "||" for guard clauses to catch failing operations, along with the use of a block statement for running multiple operations "{ }".
Like so:
Like so:
# Download the binary
wget --quiet --output-document /usr/local/bin/mybinary "$download_url" || {
error 'Failed downloading the CLI'
exit 1
}
debug "Making CLI executable"
# Make it executable
chmod +x /usr/local/bin/mybinary || {
error 'Failed making CLI executable'
exit 1
}
Is that really better than
I know someone who wrote most of his Bash that way, using `cmd && { ...; }` instead of `if cmd; then ...; fi` and `cmd || { ...; }` instead of `if ! cmd; then ...; fi`. I never thought it was particularly clear or maintainable--that it was more on the "clever" side than on the "clear" side.
Sure, it's a little clunky to have an `if` for everything that might fail, but uh... these days I write Go for a living.
if ! wget --quiet --output-document /usr/local/bin/mybinary "$download_url"; then
error 'Failed downloading the CLI'
exit 1
fi
I know someone who wrote most of his Bash that way, using `cmd && { ...; }` instead of `if cmd; then ...; fi` and `cmd || { ...; }` instead of `if ! cmd; then ...; fi`. I never thought it was particularly clear or maintainable--that it was more on the "clever" side than on the "clear" side.
Sure, it's a little clunky to have an `if` for everything that might fail, but uh... these days I write Go for a living.
My brain parses that || as quickly as it verifies the !, and having the actual command at the left of the line is helpful for clarity; FWIW, this is actually a pretty common paradigm in many languages including Ruby--with "or die"--which people generally liked for cute syntax.
Yep, this was a common Perl construct as well, since you could follow "or die" with a custom error string. I used to amuse myself (way back in the Stone Age, when I was in college and didn't know better) by using amusing and unique invectives for error messages like 'or die "you son of a motherless goat"'. Not only did they make me giggle a little, they made searching code for the line that failed a little easier...
Yeah yeah yeah, but citing Perl to defend that something is readable doesn't win arguments ;P.
Well, some parts of Perl actually make a lot of sense.
What did Larry Wall do to deserve that? Ruby cribbed the "or die" idiom (and others) from Perl because they were useful. At least let him own his good ideas along with the rest of the language.
I mentioned that these days I write Go for a living, which involves a lot of:
I think a single-line `cmd || die "msg"` like in Perl or Ruby is handy and fine. Or maybe even a two-line
if err := thingThatMightFail(); err != nil {
...
}
I think a single-line `cmd || die "msg"` like in Perl or Ruby is handy and fine. Or maybe even a two-line
some command that might fail ||
die "Some message that is long enough that it wants to be its own line"
unless thingThatMightFail
...
endI think you answered your own question. Those `if` constructs are indeed clunky. In fact I'd venture to say it's really just "C-like language Stockholm syndrome" that makes them feel more "maintainable" or "clear".
The bash "or" syntax reads very clearly. Do X or do Y. Do X or fail like so. It's very English-like and intuitive. And understanding why it works is just a matter of understanding logical operator short circuiting, which you have to understand to work in C-like languages anyway.
The bash "or" syntax reads very clearly. Do X or do Y. Do X or fail like so. It's very English-like and intuitive. And understanding why it works is just a matter of understanding logical operator short circuiting, which you have to understand to work in C-like languages anyway.
Problem is you have to fork subshells if here is any sequencing involved. Compare
if condition ; then
command1
command2
else
command3
command4
fi
condition && (command1; command2) || (command3; command4)
[deleted]
Protip:
die() { echo "$@" >&2; exit 1; }
wget --quiet --output-document /usr/local/bin/mybinary "$download_url" ||
die 'Failed downloading the CLI'
chmod +x /usr/local/bin/mybinary ||
die 'Failed making CLI executable'
Pro-protip: don't use echo.
Another common style guideline is to include context for the diagnostic, often prepended. For example,
# panic STRING-FORMAT [...]
#
# write printf-formatted message to stderr, prepending
# script name, and exit failure
panic() {
printf "%s: %.0s${1}\n" "${0##*/}" "$@" >&2
exit 1
}
Another common style guideline is to include context for the diagnostic, often prepended. For example,
wget --quiet --output-document /usr/local/bin/mybinary "$download_url" \
|| panic '%s: unable to download' "$download_url"I'll use what I can read. I can't parse that at a glance, and won't use it.
The real pro tip is: don't use bash if it's not trivial to read
The real pro tip is: don't use bash if it's not trivial to read
It's not Bash. I purposefully stick to POSIX shell constructs because memorizing all the various Bash (and ksh and Zsh) extensions and their oddball semantics is too much trouble. By sticking to POSIX shell it's easier to learn and remember actual shell programming semantics--parameter expansion, positional parameters, pathname globbing, etc. You have to understand those things, anyhow, if you actually care to understand the language; they happen whether you know it or not, and they're fundamental to the language.
Plus, the POSIX specification for the shell is significantly more concise and clear than the manuals for Bash, Zsh, etc. See Shell & Utilities -> Shell Command Language at https://pubs.opengroup.org/onlinepubs/9699919799/ I know exactly where to go if I can't remember the difference between ${foo:-X} vs ${foo+Y}.
Plus, the POSIX specification for the shell is significantly more concise and clear than the manuals for Bash, Zsh, etc. See Shell & Utilities -> Shell Command Language at https://pubs.opengroup.org/onlinepubs/9699919799/ I know exactly where to go if I can't remember the difference between ${foo:-X} vs ${foo+Y}.
Pro-protip tip: Add $0 but don't do pattern expansion. Worst case it's just slightly more verbose output. Best case, it's simpler to understand & maintain, and showing the path to your script will help unfamiliar people locate it quicker for debugging. (& I think it looks cleaner)
Also, don't run a command that directly overwrites a file unless you know it's going to succeed. A temp file lets you atomically replace the file only if the download succeeded. And a cleanup trap helps clean this up in the event of errors. Finally, you can die on unset variables or errors (cleanup still works) and you can enable tracing if environment variable DEBUG=1 was set.
Also, don't run a command that directly overwrites a file unless you know it's going to succeed. A temp file lets you atomically replace the file only if the download succeeded. And a cleanup trap helps clean this up in the event of errors. Finally, you can die on unset variables or errors (cleanup still works) and you can enable tracing if environment variable DEBUG=1 was set.
#!/usr/bin/env sh
set -eu
[ "${DEBUG:-0}" = "1" ] && set -x
cleanup() { rm -f /usr/local/bin/mybinary.tmp ; } ; trap cleanup EXIT
panic() { printf "$0: Error: %s\n" "$1" >&2; exit 1; }
mkdir -p /usr/local/bin
[ -e /usr/local/bin/mybinary ] || \
wget -q -O /usr/local/bin/mybinary.tmp "$url" \
|| panic "wget was unable to download '$url'"
mv -f /usr/local/bin/mybinary.tmp /usr/local/bin/mybinarywhy is printf preferable to echo here other than formatting?
Echo is defined differently in different shells ("not portable"). Also it can have arguments which breaks things sometimes:
echo Option -n invalid # OK
echo -n is not valid # Uh oh
printf '%s ' -n is not valid # Always okay
panic() { printf '%s\n' "${0}: ${*}"; exit 1; }
panic "${download_url}: unable to download"[deleted]
Use logger and push your messages to syslog, and aggregate using your favorite tool.
https://linux.die.net/man/1/logger
https://linux.die.net/man/1/logger
proprotip:
in the beginning of your scripts put:
set -e # stop script if error set -u # stop with undefined var set -o pipefail # stop with pipe fail
Now your scripts will have a sane default behavior
in the beginning of your scripts put:
set -e # stop script if error set -u # stop with undefined var set -o pipefail # stop with pipe fail
Now your scripts will have a sane default behavior
I start all/most of my shell scripts with
Only word of warning here is that -x can print out secrets if you're not careful.
#!/usr/bin/env bash
set -xeuo pipefael
-x to print the commands
-e to exit on error
-u to error out if there are unbound variables
-o pipefail to exit if a command that's not the last in a pipeline fails
Only word of warning here is that -x can print out secrets if you're not careful.
I stopped using `set -e`. It is disabled if the function you're running is part of an `if` statement, for example:
If "thingThatCanFail" is called _outside_ of an if statement, then `set -e` causes different behavior (i.e. step three _is_ skipped).
I instead use lots of chaining with && (as in the article), or explicit checks after each command. I have two utility functions I define in nearly every script:
thingThatCanFail() {
echo "step one succeeded"
echo "step two failed"
false
echo "step three was run too"
}
if ! thingThatCanFail; then
echo "thingThatCanFail failed!"
fi
If "thingThatCanFail" is called _outside_ of an if statement, then `set -e` causes different behavior (i.e. step three _is_ skipped).
I instead use lots of chaining with && (as in the article), or explicit checks after each command. I have two utility functions I define in nearly every script:
warn() { >&2 printf "%s\\n" "$*"; }
abort() { warn "$@"; exit 1; }
stepOne || abort "step one failed"
stepTwo || abort "step two failed"
...
That's the same approach I am using in all my scripts. You can even combine that with `set -e` and run some
Bonus note: The notation "do something else die 'with message'" stems from Perl, AFAIK. See for instance https://perldoc.perl.org/Carp
commandThatMayFail || true
Bonus note: The notation "do something else die 'with message'" stems from Perl, AFAIK. See for instance https://perldoc.perl.org/Carp
[deleted]
I developed this style at Bazarvoice about 15 years ago. :-)
'cmd && do_sth || do_sth_else' is not equivalent to if else
https://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7...
https://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7...
Do yourself a favor and read the linked section. The "elegant" method sure can be nice, but comes with a downside you really need to be aware of.
I love shell scripting and this highlights one of the major problems with bash: small changes like this can appear completely interchangeable with other mechanisms for doing the same thing but introduce edge cases that can unexpectedly bite you.
For example... consider what happens if "[ $foo -eq 0 ] && /bin/do-something" is the last statement within a function or the end of your script.
I love shell scripting and this highlights one of the major problems with bash: small changes like this can appear completely interchangeable with other mechanisms for doing the same thing but introduce edge cases that can unexpectedly bite you.
For example... consider what happens if "[ $foo -eq 0 ] && /bin/do-something" is the last statement within a function or the end of your script.
I came here to make this comment. It really needs to be a top-level comment and at the top.
I have wasted many hours of my life tracking down buts where the idiom in the OP was used in a function. It leads to really hard to find bugs.
Beware!!!
I have wasted many hours of my life tracking down buts where the idiom in the OP was used in a function. It leads to really hard to find bugs.
Beware!!!
I cannot believe this is not at the top. Short-circuiting is useful and fun in places, but to suggest it as a general replacement for conditionals as the OP does is absolutely wrong and will cause bugs.
Does this caveat still apply when you only use a single short-circuit operator in a given command? As a long time shell scripter I'd honestly be a little afraid to use more than one at a time.
I always found it delightful how `if [ condition ]` works in bash, which, in case you don't know: the way `if <something>` works in bash is that <something> is a command that runs like everything else in bash. If the command succeeds (i.e. if the return code for the process is 0), the body of the if executes.
So how does `if [ <condition> ]` work then? Is it some kind of special case? No! The way it works is that there's an executable named `[` in UNIX that that takes the condition expression as arguments, and returns "success" or "failure" depending on if the condition evaluates to true. It's right there in the filesystem at /bin/[
Now, some sticklers might argue that maybe not the greatest idea to spawn a process every time you need to evaluate an if statement, but I really do admire the UNIX purity of it: of COURSE that's how bash conditionals work! This is UNIX, after all! Why add an expression parser/evaluator to bash when you can just have it's own process for that? Do one thing and do it well!
So how does `if [ <condition> ]` work then? Is it some kind of special case? No! The way it works is that there's an executable named `[` in UNIX that that takes the condition expression as arguments, and returns "success" or "failure" depending on if the condition evaluates to true. It's right there in the filesystem at /bin/[
Now, some sticklers might argue that maybe not the greatest idea to spawn a process every time you need to evaluate an if statement, but I really do admire the UNIX purity of it: of COURSE that's how bash conditionals work! This is UNIX, after all! Why add an expression parser/evaluator to bash when you can just have it's own process for that? Do one thing and do it well!
It is neat, but it also trips up a lot of us in the beginning. Because at one point you instead write: 'if [condition]' and get weird errors. And you can't understand how suddenly you can't even do a simple if-statement.
And there are tons of gotchas like that that made me terrified of bash. Even the simplest construct can attack you from any angle and the trial and error and distrust is everywhere. I'm getting better at it but for me and I guess many others, I just don't use bash enough to remember these quirks and the resulting experience is rather poor. Which is a shame!
The savior for me was shellcheck. Instead of needing character-perfect memory of each construct and common snippet I can run shellcheck on it and it will tell me what common pitfall I might have stumbled upon and most importantly, why it is an issue. For a beginner I think it is an absolute must.
And there are tons of gotchas like that that made me terrified of bash. Even the simplest construct can attack you from any angle and the trial and error and distrust is everywhere. I'm getting better at it but for me and I guess many others, I just don't use bash enough to remember these quirks and the resulting experience is rather poor. Which is a shame!
The savior for me was shellcheck. Instead of needing character-perfect memory of each construct and common snippet I can run shellcheck on it and it will tell me what common pitfall I might have stumbled upon and most importantly, why it is an issue. For a beginner I think it is an absolute must.
Actually... it usually is a special case. For performance reasons there are some sneaky things Bash tends to do to avoid spawning lots of extra processes. In this case the `[` binary is more for backwards compatibility.
You can verify this by writing a simple test script and doing (at least on Linux) "strace ./test.sh 2>&1 | grep exec" and observe no explicit call to that binary.
You can verify this by writing a simple test script and doing (at least on Linux) "strace ./test.sh 2>&1 | grep exec" and observe no explicit call to that binary.
Because Bash already has an expression parser/evaluator that it uses for this case, so now there isn't just one thing doing it, there are two, and you have to know when they are used and when they aren't.
Honestly the idea that a certain benign-looking syntax could (but maybe not!) spawn some external subprocess is terrifying to me, and I don't find it delightful at all.
Honestly the idea that a certain benign-looking syntax could (but maybe not!) spawn some external subprocess is terrifying to me, and I don't find it delightful at all.
There is some special casing in the ifs conditions though.
Even if you `set -e`, the command in the test can fail and your script won't exit.
Even if you `set -e`, the command in the test can fail and your script won't exit.
While it might not be a special case exactly, you most likely won’t see /bin/[ being executed either. Typically your shell will implement it as a built in command. Because as you say, spawning processes is expensive.
You should not overuse chaining of commands. It obscures individual exit status, it can fail in subtle ways (esp. with features like set -e or pipefail), eventually you'll need to refactor it to do something more complicated, and it can hide important behavior from the casual reader.
Parameter expansion is a great way to simplify your code, but it can be obtuse to the casual reader. Setting a default variable using DEFAULT="${DEFAULT:-myvalue}" is a bit easier to understand than just ${DEFAULT:=myvalue}.
Read the dash manual and try to stick to just those features as it's almost entirely POSIX. Most scripts do not need to rely on bash functionality. https://linux.die.net/man/1/dash
If you find it will really simplify your life to have arrays, hashes/maps/dicts, a while loop reading from a subshell's output, etc, then use Bash and use those features. Otherwise, stick to POSIX semantics. You can do almost everything you need with parameter expansion, expr and other unix tools.
With any programming language, you should try to use the least amount of syntax and functionality possible to accomplish your goal, as long as it is readable, maintainable, and does not hide tricky behavior. Being verbose is always preferable to being hard to maintain; verbose and uncomplicated things can easily be simplified later.
Parameter expansion is a great way to simplify your code, but it can be obtuse to the casual reader. Setting a default variable using DEFAULT="${DEFAULT:-myvalue}" is a bit easier to understand than just ${DEFAULT:=myvalue}.
Read the dash manual and try to stick to just those features as it's almost entirely POSIX. Most scripts do not need to rely on bash functionality. https://linux.die.net/man/1/dash
If you find it will really simplify your life to have arrays, hashes/maps/dicts, a while loop reading from a subshell's output, etc, then use Bash and use those features. Otherwise, stick to POSIX semantics. You can do almost everything you need with parameter expansion, expr and other unix tools.
With any programming language, you should try to use the least amount of syntax and functionality possible to accomplish your goal, as long as it is readable, maintainable, and does not hide tricky behavior. Being verbose is always preferable to being hard to maintain; verbose and uncomplicated things can easily be simplified later.
Strongly disagree on elegance of [[ condition ]] || cmd and [[ condition ]] && cmd.
Every developer has read enough if statements to understand if then else at a glance. Few people write enough bash scripts to have that same instant parsing of [[ condition ]] && cmd or [[ condition ]] || cmd, especially when intermingled.
I like the idea of cmd || { raise error; } that others have mentioned, but I hate the idea of using these in place of an if statement to save 2 lines.
Every developer has read enough if statements to understand if then else at a glance. Few people write enough bash scripts to have that same instant parsing of [[ condition ]] && cmd or [[ condition ]] || cmd, especially when intermingled.
I like the idea of cmd || { raise error; } that others have mentioned, but I hate the idea of using these in place of an if statement to save 2 lines.
condition && action
condition || action
I prefer || and && because I can never seem to remember the bash `if` syntax.
Sure, it's weird to write (`then` is a separate statement, it has to end with `fi`, that's different), but I prefer making things easier to read than write. I believe that it's easier to read that boilerplate even if you have to look up how to write it.
[deleted]
I guess I've been reading that construction long enough that it's obvious (at least to me). It's also helpful that the same construction is common in obfuscated and tightly-compiled Javascript...
Original article:
>The echo command always exists [sic] with 0, so this propagates to exit if the first expression is truthful. (emphasis his)
In both bash and dash (and probably most), echo will fail if there is no stdout. E.g.:
EDIT: Also note that not exiting the script could cause a flurry of cascading errors (likely permission errors in the article's example).
>The echo command always exists [sic] with 0, so this propagates to exit if the first expression is truthful. (emphasis his)
In both bash and dash (and probably most), echo will fail if there is no stdout. E.g.:
j.sh:
echo hello && exit 2
$ bash j.sh >&-
j.sh: line 1: echo: write error: Bad file descriptor
$ echo $?
1
EDIT: Also note that not exiting the script could cause a flurry of cascading errors (likely permission errors in the article's example).
> Ughh. Let's improve!
I really don't understand what is the problem with that simple if statement to receive this kind of reaction. :shrug:
I really don't understand what is the problem with that simple if statement to receive this kind of reaction. :shrug:
The traditional format of Bash's if/then has `if` and `then` on separate lines:
I always inline the `then`, which requires a semicolon:
if command_or_condition
then
branch
fi
I always inline the `then`, which requires a semicolon:
if command_or_condition; then
branch
fi
I use:
if command_or_condition
then branch
more_branch
fi
How swapping a '\n' char for a ';' is less "wasteful" or "ugly"?
I agree. Also, not sure what's being improved. I also would have expected to run into a reference of double and single brackets used in if statements, e.g. [[ ]] and [ ] -- which I always seem to find confusing.
[[ ]] is effectively an entirely different parser than the surrounding shell, similar to (( )).
so you can do things like
so you can do things like
[[ 1 < 2 ]] && echo true # where < is now not redirect, like to (( 1 < 2 ))
[[ "x" == 'y' || x == x ]] # note how || is not behaving the same as [ '' || 'y' ]
The [ character is actually the program called "test"[1], so you can think of it as just running grep or sed or any other external binary/program, whereas the [[ replacement is shell-specific builtin; this blog is not using "bash-ism" but instead the external test operator from `coreutils` which generally would work from sh, zsh and whatever but on zsh, it doesn't work the same (kinda, it's more that the comparison EQUALS operator doesn't work well with [ but it's fine with [[).
Here it is in pdksh:
This got kinda long sorry, hope it helps.
[1] there's actually a binary "[" and a binary "test" in the `coreutils` package on most systems, however I'm not sure why they have different binary file sizes to be honest
[2] https://linux.die.net/man/1/pdksh search "[["
[3] https://www.zsh.org/mla/users/2011/msg00161.html
Here it is in pdksh:
# [ "Z" == "z" ] && echo Bob
# [ "Z" == "Z" ] && echo Bob
Bob
# [[ "Z" == "Z" && "A" == "A" ]] && echo Bob
Bob
# [ "Z" == "Z" && "A" == "A" ] && echo Bob
pdksh: [: missing ]
# [[ "Z" == "Z" && "A" == "A" ]] && echo Bob
Bob
# [ "Z" == "Z" && "A" == "A" ] && echo Bob
-bash: [: missing `]'
# [[ "Z" == "Z" && "A" == "A" ]] && echo Bob
Bob
# [ "Z" == "Z" && "A" == "A" ] && echo Bob
zsh: = not found
# if ([ "Z" == "Z" ] && [ "A" == "A" ]); then echo Bob; fi;
Bob
# if [ "Z" == "Z" ] && [ "A" == "A" ]; then echo Bob; fi;
zsh: = not found
# if [ "Z" '==' "Z" ] && [ "A" '==' "A" ]; then echo Bob; fi;
Bob
This got kinda long sorry, hope it helps.
[1] there's actually a binary "[" and a binary "test" in the `coreutils` package on most systems, however I'm not sure why they have different binary file sizes to be honest
[2] https://linux.die.net/man/1/pdksh search "[["
[3] https://www.zsh.org/mla/users/2011/msg00161.html
This is bad advice if you want to write reliable and maintainable shell scripts.
> We can simplify this using control operators:
Almost. The real way to do this is to check for the non-existence of the file as the “success” case and do the action via a || on failure.
Otherwise if you run in a strict mode with error on any unhandled non-zero command (set -e), you’ll exit the script with failure when the profile doesn’t exist:
[ -r ~/.profile ] && . ~/.profile
Almost. The real way to do this is to check for the non-existence of the file as the “success” case and do the action via a || on failure.
Otherwise if you run in a strict mode with error on any unhandled non-zero command (set -e), you’ll exit the script with failure when the profile doesn’t exist:
[[ ! -r ~/.profile ]] || . ~/.profile
Mentioned in the artice is:
cat ~/.profile && echo This is your profile || echo Failed to read profile
I think these are commonly called short-circuits. Using these with brackets too, in order to gain greater control or more complex comparisions is super useful if not aware of it.
A simple example would be something like:
# (foo && bar) && (bish || bash) && echo 0 || (echo "not bosh" && exit 1)
I'm no bash expert, just a sysadmin with a little dangerous knowledge, but constructing things that way just feels more natural (to me, at least, it's probably 'teaching your grandmother to suck eggs' to a proper bash hacker).
cat ~/.profile && echo This is your profile || echo Failed to read profile
I think these are commonly called short-circuits. Using these with brackets too, in order to gain greater control or more complex comparisions is super useful if not aware of it.
A simple example would be something like:
# (foo && bar) && (bish || bash) && echo 0 || (echo "not bosh" && exit 1)
I'm no bash expert, just a sysadmin with a little dangerous knowledge, but constructing things that way just feels more natural (to me, at least, it's probably 'teaching your grandmother to suck eggs' to a proper bash hacker).
You can group with curley braces too. This can be especially useful for input/output redirection over a chunk of commands.
Be careful with using parenthesis -- this means you're now in a subshell! That "exit 1" will NOT terminate the entire script, but instead set "$?" to 1 for the next command. Additionally, any variable or environmental changes will be lost (which may be desirable) once you're outside of that block.
Be careful with using parenthesis -- this means you're now in a subshell! That "exit 1" will NOT terminate the entire script, but instead set "$?" to 1 for the next command. Additionally, any variable or environmental changes will be lost (which may be desirable) once you're outside of that block.
Thanks for the tip! I knew what I was doing was probably not right, but it worked when I needed it in the past (probably because of setting pipefail). It's very much welcome to know how to do it better :)
Curly braces will fail in `dash` which may be what your /bin/sh is (or could become).
Curly braces are POSIX and work fine in dash. (Perhaps when testing you forgot these restrictions, which are the same as in bash: there must be whitespace after {, and a newline or semicolon before }.)
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
You are right. Apologies. Seemingly from this [1], quoting such braces was initially recommended.
[1] https://www.cs.ait.ac.th/~on/O/oreilly/unix/ksh/appa_02.htm
[1] https://www.cs.ait.ac.th/~on/O/oreilly/unix/ksh/appa_02.htm
There’s a typo on this line; a semicolon or newline is required before }:
-[ $EUID -ne 0 ] && { echo You must be root; exit 1 }
+[ $EUID -ne 0 ] && { echo You must be root; exit 1; }And also the same typo on the more general line just above what @anderskaseorg mentions (i.e. `{ expr }`) which should read `{ expr; }` (or line breaks instead of leading space/ trailing ';', etc. Such quirky syntax.)
Both of the suggestions lead to overly brief and harder to read one liners, imo.
Explicit if [].. is more readable.
Chaining commands with && is better just accomplished by running `set -e` which you should be doing at the start of your script anyway.
And of course both of these are getting pretty close to the "if you have to Google what this bash syntax does, just write your script in Python" rule.
Explicit if [].. is more readable.
Chaining commands with && is better just accomplished by running `set -e` which you should be doing at the start of your script anyway.
And of course both of these are getting pretty close to the "if you have to Google what this bash syntax does, just write your script in Python" rule.
I use these, but only as what are effectively assertions:
[[ -f $input_file ]] || { echo "${input_file} does not exist"; exit 1; }
> [ $USER != "root" ] && echo You must be root && exit 1
I get that the authors point was more focused on the conditional usage, but this seems like a pretty bad way to check if the user is root and isn’t really any more complicated than checking EUID = 0 or some of the other methods.
I get that the authors point was more focused on the conditional usage, but this seems like a pretty bad way to check if the user is root and isn’t really any more complicated than checking EUID = 0 or some of the other methods.
This is one of those articles written by someone who wants to make themselves look important but doesn't really understand the language/tool they are demonstrating. $_ shouldn't be used in scripts but is okay for an interactive session. Also he uses compound commands such as { cmd1 ; cmd2 } without the semicolon req: { cmd1 ; cmd2 ; }
I'm not entirely sure what I think of "x or y" replacing "if not x then y", but it's a common enough idiom that I don't have trouble reading or writing it.
I have tended to use it more recently for vertical compactness, and in python because pylint doesn't like single-line if statements but happily tolerates "x or y".
I have tended to use it more recently for vertical compactness, and in python because pylint doesn't like single-line if statements but happily tolerates "x or y".
To add to the OP:
you can use '(' and ')' for grouping, so this is possible too:
( foo && bar && baz ) || ( fallback1 && fallback2 ) || echo 'Argh, even fallback failed!'
Beware that using parentheses spawns a subshell. That’s another bunch of “interesting” side effects.
{;} is command grouping. () is a subshell. That example is very naughty and should never be seen in a real script.
From personal messing around in the past, ||/&& generally don't seem as performant as using plain statements, by a fair margin (I'm guessing its causing subshells to be spawned for whatever reason, but I didn't bother digging further)
just use zsh.
`if [[ -f file ]] {run this command} else {run that command}`
no closing `fi`, use multiline or single line, add an arbitrary number of elif statements. this only requires the short option is set in your z shell.
no closing `fi`, use multiline or single line, add an arbitrary number of elif statements. this only requires the short option is set in your z shell.
and I'd call most of this discussion flow control, not conditionals. Strictly speaking, conditionals are one of the primary benefits of zsh over bash imo.
Bash plus any attempt at expressiveness equals Perl. There I said it, I’ll accept my downvotes
"Elegant" and "bash" are two words which cannot go in the same sentence.
Only for some very specific, non-traditional definitions of the word "elegant".
Just use byron's rc shell:
if (condition) { statements; } else { do other thing; }
if (condition) { statements; } else { do other thing; }
There will be people - seasoned professional developers, even - reading these languages that don't know the first thing about them!
`[` is one of those things that are second nature for seasoned bash people but that are utterly ungoogleable by a bash beginner. Beginners don't know `[` is an executable, and it would never occur to them to `man [`. It can become quite the rabbit hole to figure out that there's also `[[` (which is NOT an executable), that `[ a > b ]` is very very different from `[[ a > b ]]`, etc.
So do these people a favor and put the `if` there so they at least have some hope of stumbling upon a stack overflow post talking about some of this stuff.