Never say "If" writing a Bash script! (Exit codes & logical operators)
Вставка
- Опубліковано 18 бер 2020
- A good rule of thumb is to never use "if" statements when writing shell or bash scripts. 90% of the time, you can get what you want more elegantly just with logical operators like && and ||. It makes the difference between ugly and elegant looking and running code.
WEBSITE: lukesmith.xyz 🌐❓🔎
DONATE NOW: lukesmith.xyz/donate 💰😎👌💯 - Наука та технологія
Boomer avoids the stress of the apocalypse by obfuscating his bash scripts
Are you guys ready for the boog?
I'm gonna go and strip all the newlines out of my C++ code and see if it makes me feel better about myself.
@@superscatboy It could make the file smaller.
@@LaughingOrange Lol yep I've been meaning to free up a kb or two of disk space ;)
I'm starting to suspect this is a parody channel giving bad advice. Imagine someone reading your script and not knowing what || is, how do they even google that?
An if is an if, everyone understands that.
Be careful with exit codes. They can ditch you in some cases.
Also, scripting is not just for looking elegant/beautiful, it should be functional, performance tuned, easy to read/understand, easy to maintain, new-developer friendly, easy to debug, modularized and so on.
Everything should be used judiciously.
You will come to know what is best if you start working in real-time.
Yes, you are right, we should give Luke a few hints:
$ false && echo hello && echo ok
$ if false; then echo hello; fi && echo ok
@@alexanderelgert6037 What is this example supposed to show? those commands are not equivalent.
The second command is logically something like:
$ (if false; then echo hello; fi) && echo ok
Which would be equivalent to
$ (false && echo hello || : ) && echo ok
*brackets are unnecessary but make it easier to understand
Maybe your point was that it's easy to get confused, but it's not more complicated than understanding the order of operations in mathematics
Terry Davis always said that the CASE statement was divine
Lisperati know when not if.
On that note: I wonder if there is a way of building a Duff's Device in Bash.
Not going to say it's impossible, but maybe. It'd work if you disentangle the switch from the loop, but the entire thing is academic since shells are so slow.
The CIA tried so hard to convince us that if/else statement is the same as switch statement but lucky for us terry teach us this divine intellect .
It was invented by Tony Hoare. What was remarkable was that it could be implemented with essentially zero run-time overhead.
Hoare was also one of the proponents of “structured programming”. Which I feel is underrated these days, where I see C code especially using gotos like they’re going out of fashion.
It's worth noting that Luke uses these compact forms in a way that makes his code more legible.
which is generally harder to do than making the code more legible with control flow statements for people unfamiliar with 'points free'/stream oriented programming. You pick your battles. If most of the code you are writing is bash scripts, its worth focusing on. If not, you are going to waste a lot of time 'mode switching' into stream-centric/points free programming style.
yup, the code example he showed was much easier to read than the large if-blocks that I have been guilty of writing lol
You can group expressions with curly brackets:
{ command1 || command2 ;} && { command3 || command4 ;}
Or more complex. The brackets also make it easier to understand the code IMHO.
BUT what you call elegant I call ugly and bad readability. I use this in my code but at least I don’t claim it to be beautiful or elegant. You got a negative from me today.
You and I have different definitions of "elegance". I can understand your preference for concise code, which is the traditional spirit of Unix/Linux. I, on the other hand, want my code to be readable by newbs in a corporate environment long after I've gone. I don't really consider your examples obscure for someone who has knowledge of bash, but using structures (like if statements) that are recognizable to users of other programming languages with no training in bash is also "elegant"
When I am writing bash script I usually comment to the point of obsession to make sure anyone new to my script (or bash) has an idea of what code does. It's a bit more work but it makes sure that I get a piece of concise code while also makeing sure people understand what is happening
@@alexandrep4913 Unless that junior programmer was explicitly hired to write Bash scripts, your reasoning is self-centered and dangerous.
If you don't help them, they'll go online to find an answer. Which may not be how you want things done resulting in you helping them anyway but with a lot of time wasted in between. Also your argument about code not being around shows a total lack of real world experience. Plenty of corporations have code written DECADES ago still running somewhere in their organization.
@@alexandrep4913 lol wut? 😆 you think some one comes and removes your code after you leave a company?
that shit is sticking around until it breaks, and then the person who has to work on it benefits greatly if you have written expressive code
this..
there's basically no cost to using 3 lines for an if over 1
but there's a huge reward that java/python/javascript developers can pattern match a bash if against what they're used to
@Evan John Programming ¯\_(ツ)_/¯
Neat info. Definitely some next level bash for 90% of circumstances. Good to see you back at it, Luke.
One more thing: The following does *not equal* to an if else:
condition && statement1 || statement2
because if the condition is true and the statement1 fails statement2 will be executed as well!
So, only statements should be used when doing this?
grouping stuff together should fix that though. Not sure about the shell syntax, but I’m guessing it would be something like:
[ condition && statement1 ] || statement2
or
$( condition && statement1 ) || statement2
where what’s logically happening is condition fails, which makes statement1 get skipped because of &&, which triggers statement2 to be executed because of ||. Again, I’m not sure so please correct if wrong
Actually, it "may" execute the || or else, but only when the last command executes. Inside curly brackets, you can have non-zero exits, so long as your final command exits 0. In that case, curly braces allow you to use % to find the end of your "if/else", rather than sorting through several layers of if/fi, which is the further issue of over using else. Conditionals should be used to reduce indentation, not evil.
Sorry about the reply on an old video - I think it's worth adding to this that functions can use the RETURN command to return an error level value (e.g. 0, 1, etc.) based on outcome which can be combined in this manner to produce a cleaner main body structure within the main script. It lets you homogenise (and potentially re-use) those segments a bit more too; perhaps even going so far as to offload those tests to another shared script and use the SOURCE command to re-use them. Not sure if that's considered heresy, I'm just trying this out at the moment.
If you use
set -e
in your script the script will fail if any of the commands fail, so you don't need to type && all the time. I set it in most scripts.
Then where is
set -u
as well. This is really helpful, as the script immediately fails if it encounters an undefined variable. This will also disarm bombs such as rm -r "$DIR/$SUBDIR", if one of these variables is not set.
Good point - for the second example, if I ever do a rm command with a variable followed by a slash "/" I use parameter expansion with a dummy name to protect against an unset variable causing the path to start from the root directory (not that I _ever_ had this happen in one of my production scripts ;-).
/bin/rm -r "${DIR:-NULL}/$SUBDIR"
Nice, I really appreciate you make those simple to novice!! Great work!!
This video really helped me clean up some shell scripts that I have recently made. Thank you brother, and God bless
"[" is a command (it more or less aliases to "test"). So when you do `[ -z "$EDITOR" ] && do_smth`, the if is not technically implicit.
Same for me. But did you also know that bash has a builtin help system? help [ gives you some overview, they call it a synonym for test
🤯
@@Ultr4noob Me too, I was telling myself why do there need to be spaces at places where you don't expect them to be necessary. When I realized it was a regular old executable that simply required it's last argument to be "]", then it made sense.
It also blew my mind.
@@techtutorvideos you don't even have to have the ; :D
interesting
the difference in this suggested style and if-else is that,
in this one, all the statements (actions) are the expressions too (aka conditions).
whereas in if-else, the expression is separate than the statement.
Instructions unclear; ended up with a plan 9 emulator in a bash script.
🥂, you reminded me of the classic: Instructions unclear, d!ck stuck in fan.
; does change its mind if you run with set -e, which you always should. And " mayfail || true" is used to ignore it. Typical problem "cd x ; rm -rf *" can fail horribly. (You can use && instead, but it's additional work to remeber it. Especially if you use no ; but next line). Pro tip for ad-hoc scripts. BTW instead of if/|| you can use default value for variables ${EDITOR:-nano} (or :=)
I only do casual bash scripting, so this is completely new information, thanks and happily subscribed!
The recommended approach here almost sounds like nested try catch blocks, which is pretty neat.
(try this. Pass? try next. Pass? try next. Fail. Enter catch block through || and stop trying)
Will you cover how you would handle user inputs, or have you covered that already?
Been looking to get bit better with my shell scripting this helped a bunch .
This was really helpful. I was using xrandr to switch between laptop screen and monitor and the thing is that I only want to turn off one screen *if* the other is succesfully activated. Otherwise I don-t want to turn it off. Perfect use case in my mind.
OMG, such a simple explanation about BASH, the semi-colon, which I hate in all languages, but you've explained it so easily.
I really needed this video, time to optimize sum scripts, also in what kinda situtations you DO actually need to use the if statement
I use nested if more often these days. I think it more clearly describes my intent and makes revisiting older scripts easier.
This was really nice and enlightening. Thank you.
That semicolon saved me! Was using && in the wrong place, thank you.
This video was actually helpful to me: Now I know to not use "&&" all the time. I used to think that that was required to guarantee that a command only starts after the previous one executes, but actually ";" does that as well. So I'll do exactly the opposite of what you suggested from now on. Because using "&&" actually just tells the console to evaluate a condition and then to not do anything with it. And evaluating that condition has "side effects", which are the actual commands you want to run. That is certainly not intended.
I just jumped to a WM next up is to learn some bash scripting for fun so thanks for the new videos.
The videos in your reboot so far have been fantastic.
Functional programming in shell script has never been so real and possible for me. Thank you! I learn a lot from you.
Thank you for that video && especially for the last example cause logical operators really can do very special thing
the & character puts the job in the background. The number before the process id is the job number. fg 1 would bring it back into the foreground. jobs will list background jobs and their job numbers. Cntrl z will put a running job into the background, and kill %1 will kill job #1, etc.
I love your videos, thank you so much for making amaaazing terminal videos
Beautiful explanation, Luke!
This reminded me of a cool bash language feature I just learned when writing a script at work today!
$ [ -z $EDITOR ] && EDITOR=nano ; echo $EDITOR
...Can become
$ echo ${EDITOR:=nano}
Check out the "Parameter Expansion" section in the bash man page.
${parameter:=word}
Assign Default Values. If parameter is unset or null, the expansion of word is assigned to parameter. The value of parameter
is then substituted. Positional parameters and special parameters may not be assigned to in this way.
There are a bunch of cool features here!
I think the use of logical operators instead of "if" statements makes sense when working in a terminal. In a bash script I want others (and future me) to understand the code on first glance, an if statement inherently does this because it is the de facto way of controlling flow in most languages.
Looks clean to me. I write my scripts like this, _"if/then/else/fi"_ and _"command && {…} || {…}"_ look functionally identical to me.
I’m a `if test` kinda guy 😂 .. it looks better to me.
Generally, me too, for simple things.
However, like in Luke's last example, where you have a chain of half a dozen commands, each running depending on whether the previous one was successful, nesting if statements becomes really messy and it looks horrible. Especially having fi fi fi fi fi fi in the end. Yuck.
Yeah. These tutorials are interesting and good for beginners I guess, but the code produced wouldn’t pass a code review in a real software engineering firm
@ I saw something about getting the exit code from the previous command. So a way to prevent it would be to store that value and checking if 0. This way you'd avoid nested if statements and they would instead be linear.
I'm unsure if it's a realistic approach as I don't actually use this language, I just stumbled upon it, but I see no reason as to why it wouldn't work as long as you write it correctly.
The ] is a lie
To check if $VAR is unset, and give it a default value like 11:00 on video, the bourne Shell has had syntax ${VAR:=default} for over 30 years... though I know you were trying to focus on if/else style logic.
Clear readable, and reliable code is still preferred, which ever syntax is used.
; is denotes the end of a commond, & denotes the end of a command and backgrounds it, unless it is in an arithmetic expansion where it is bitwise and. && and || are logical operators, but you forgot !, which negates a value. Can test like ! true && echo hello || echo foobar.
Do you get the feeling that Bash syntax has, shall we say, evolved by accretion over time? ;)
: ${EDITOR:=nano}
And how in the name of fuck is this sorcery called? I'm looking for googleable name.
But if I export EDITOR="" it will works the same way?
@@ba-a-a www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html
@@bartolomeykant Yep
echo "export EDITOR=nvim" >> ~/.zshrc
echo "export EDITOR=nano" >> ~/.zshrc
echo "export EDITOR=nvim" >> ~/.bashrc
echo "export EDITOR=nano" >> ~/.bashrc
I’ve been up to 3 in the morning losing track of my scripts. This helps keep it simple!!! 🎉🎉
Thanks, I have always wondered how some of these complex scripts meant. I only have been doing file manipulation using grep.
Great videos, I learn a lot about bash and Linux from you. Thank you
Thank you Luke !
Thank you! Was very useful!
blowin' my mind again. Great video!
wow this is super useful, even to a bloat user like myself! thanks
It's actually bad form, what you do, Luke. At least in scripts that are supposed to be highly reliable and re-usable. In such scripts you would set `set -o errexit -o nounset -o pipefail -o noclobber` or something like that. So error codes of 0 are always errors that kill the script and variables must be set when used. With those stricter options set
`[ -z "$EDITOR" ] && EDITOR="nano"`
is an error, if there if EDITOR is unset. Twice over actually, because of `nounset` AND because a zero exit-code is not caught (the result of the square brackets). An here if-statement would not "trigger" the `errexit`, though it would still the `nounset`. So stricter scripts, youd either do:
```
[ -z "$EDITOR" ] &&
EDITOR="nano" || true
```
or use an if statement.
Also, you should wrap your actual code in a function (I often call it main) and invoke that function only when the script is run directly.
```
main() {
# your code goes here...
}
if [ "$0" = "$BASH_SOURCE" ]; then
set -o errexit -o nounset -o pipefail -o noclobber
main "$@"
fi
```
That way people can source your script and use the function without accidentally running the script or setting those stricter options.
YES, it is boiler plate but it makes bash scripts more reliable and more re-usable.
I want more of this. Thanks for sharing the wisdom.
Corona-chan is helping me learn bash script :)
@@robertkiestov3734 Unironically true and based.
@@robertkiestov3734 The "pandemic" is a real illness (I had it), but it isn't nearly dangerous enough to justify all the measures that have been taken to avoid it. It's essentially just a glorified flu. Yeah, you feel like shit for a few days, with coughing, fever etc., but it really isn't worse than just getting regular flu. Even 74 yo Trump survived it without a problem.
@@gayusschwulius8490 I don't know man. One of my dad's best friends died yesterday. My dad's 54 years old, and his friend was just a couple of years younger. Didn't have any severe health problems or anything. Some weeks ago another friend of his also died. Same story. I've just never seen the flu kill people like that.
On the other hand, I live in Brazil, and here there have been some new variants of the virus that kill younger people. Maybe in US only older and more immunologically fragile people die, but still, judging by the death count there I'm pretty sure it's more lethal than the flu.
More people have died of the “vaccine” than the virtual coof.
@@gayusschwulius8490 just because u had a cough doesnt prove the existence of a pandemic. u r brainwashed, seriously.
Thanks again. Huge help!
That would have made many of my dumb scripts easier to write. Thanks, good teaching there!
Very useful info, Luke
Can this style be used to easily replace if/elif/else type of conditionals? I guess you can do condition && cmd_true || cmd_false
But for one, this looks kind of clunky. And more importantly, this isn't even semantically the same as if/else, because if cmd_true were to fail, then cmd_false would be executed, which doesn't occur in if/else constructs.
i dont remember what semantically means 😅
but the difference in this suggested style and if-else is that,
in this one, all the statements are the expressions (aka conditions).
whereas in if-else, the expression is separate than statement.
Exactly. Bad video, poor guidance for beginners (which clearly this video is intended for). Not only are if/then's more readable, but are also absolutely necessary half of the time because AFAIK sh has no ternary operator (cond ? true : false). If typing is an issue, that's what snippets and/or keyboard shortcuts/mappings are for.
if [a] b elif [c] d else e
becomes
([a]&&b||true)||([c]&&d||true)||e||true
Thx man, very helpful information
Reminds me of the guy who said "don't nest your code" and then chained half a dozen functions together by assigning the result to available and giving this variable to the next function.
Thanks for video. This reminds me some of fuctional programming concepts. Is shell functional like language?
RESPECT!! AMAZING VIDEO GONNA START DOING THIS
I have no idea what a bash script but I knew about all of the logical operators from use in if statements ironically
EDIT: I used to think foo && bar would terminate the script in set -e mode if "foo" fails and wrote a comment to that effect. Apparently, not so. Sorry for the confusion.
I still prefer to use the "if" statement but that's mostly a stylistic preference at this point. It at least lets you add more lines in the body of the if statement later on without making your VCS diff noisy.
@vavanade Actually, looks like I was wrong about this. foo && bar won't terminate the script if "foo" fails in set -e mode. Sorry!
I have a story for you
Consider this scritp:
# warn_if_file_@t
[ -e some_file ] && echo "warning, this file exists but shouldn't"
If the file doesn't exist, this the script itself will exit with non-zero exit status. A script like this is used in my profile at work because it is part of a weird environment setup thing that everyone has to use.
When we started doing CI with gitlab, we didn't know that it activates the equivalent of set -o errexit for the jobs it runs. Our environment setup made it up to the warnings script and crashed.
When trying to hunt down the reason for the failure, we investigated the environment setup by doing part of it, then adding a bit more until we got the crash. My supervisor and I were investigating this together. When we got to this warn_if_file_exits.sh, we were going to add just that, but looking at what it did, we were both convinced that this script couldn't be the reason, so we added that and a bunch of other stuff, then we got the crash. So we had narrowed it down but the day was over so we went home.
The next day, I went back over what we did more methodically and found that it was that leaked test.
Lesson learned: Never write ifs like that.
@@PhilippeCarphin Oh, that's a good point. So even though `foo && bar` won't terminate the script for a failing `foo`, it will set the exit status if it's the last line of a script or function.
@@MatthewDeVore One of the lesser known "features" of Bash.
@@anonymousalexander6005 I didn't know that || exit will propagate an exit code. Thank you for the tip.
I've been preferring the abbreviated style suggested by Luke lately. I tend to be against verbosity in coding style. I found over time that 90% of my conditionals in shell scripting were covered by the `foo || bar` and `foo && bar` patterns. I'd rather not make something verbose and ceremonial "just in case" I may refactor it later and I want the diff to look nice.
Very useful information, great examples...but there are times when If is the best choice. For example, why did the last command fail? I like to run a logger line and dump the stderr from a command out so I can have forensic information later. If statements allow me to do thst easily. Your example with functions convinced me I need to use functions more too...
awesome guide, you explained it good, Thanks A lot
Thanks man! I'm really learning a lot with you. I appreciate the time you put into this videos.
I wrote a bash script with bitwise flags using arithmetic logic gates in this fashion, so if a specific bit was set to 1 in the flags variable, a certain process would be carried out.
Looked like this:
_(( FLAGS & FLAG_NAME )) && {_
_COMMAND_LIST_
_}_
or if a flag bit is set to 0:
_(( ~ FLAGS & FLAG_NAME )) && {_
_COMMAND_LIST_
_}_
@Terminalforlife (LL) oops! Yeah, supposed to be braces, not parentheses.
I used to use _If_ statements for all my conditional statements, until I realized I can shorthand them by just using the _[ condition ] && {...} || {...}_ syntax. After all, that's what this video is all about, but there are scenarios where an _If_ statement can't be avoided.
New sub here, I'm now checking your shell script videos, even though I'm a total noob, your explanation is so clear, do you have a class with shell scripting?
Good stuff! Thank you
Power move: your echo statements really don't need to be quoted. Sweet!
Hey Luke, love your videos, can you make on about bash scripts with named args?
The quarantine isn't all too bad if we get a Luke vid everyday
Very nice. Thanks!
awseome, thanks for that!
ED IS THE STANDARD TEXT EDITOR
cat is the standard text editor! :-p
Luke, I wish I can be as confident as you.
I don't regard if/then as "ugly," but there's no denying the && || approach is better.
Good job explaining! I am an old ninja, but I learn stuff and I enjoy these videos as nerdtainment
This is really amazing
Great tutorials.
OMG please no...!
My student sent me this video and I thought this was some April fools story, but the publication date of this video is March 19th...
This is exactly how one should *not* write conditionals in Bash and its the source of all the people there calling it a cancer language (or hard/unreadable, to put it more politely). Just don't.
There is absolutely no real cost in using 3 simple lines instead of 1-line complex statement, no difference in efficiency, while the benefits of code clearness is priceless for the long term.
The fact that the language/tool's flexibility allows one to do something, does not mean one should rely on that.
With && is all well till you use it with max 2 or 3 commands, if you are using it with miltiple commands, its just a pain to troubleshoot it after, you just need to run everything separated then
Love your videos. Been programming a long time. Question fro you. What about scenarios where if then else ? So, taking your example ([ "$a"="$b" ] && b=c || b=d ) So, if we break this down and I understand you, if a=b then b=c else b=d ? Correct ? Also, what if there is a if then elif elif else ? LMAO
Great stuff. I am baffled by a lot of the criticism I see here in the comments.
I hate being expected to learn to write lengthy, bulky and usually just ugly code for the excuse of "readability". I'm very much a beginner coder, but always look for ways of writing less code that is also clearer, which what is being shown in this video simply is to me.
It appears to me that many people have simply decided that writing more lines of code using as many human-language words as possible by definition makes things more readable. It might be sometimes, but it clearly isn't always according to some of us. Dogmatic thinking still rules the minds of many, whatever the subject matter, I will submit.
There might be two major categories of coders with regards to this issue, or perhaps context simply matters once again.
$ echo ${EDITOR:-nano}
${parameter:-word}
Use Default Values. If parameter is unset or null, the expansion of word is substituted. Otherwise, the value of parameter is substituted.
I was going to mention it too, thanks. Yeah, echo ${EDITOR:=nano}, or some other parameter expansion possibility, ${EDITOR:-nano} etc. That Luke Smith does not know the shell in-depths... just "man bash" and Read The Fantastic Manual, @Luke Smith, please
That was a good one!
this changed my world!
EXCELLENT!!! TY!!!
That's fine only if it's a simple condition without multiple instruction otherwise you have to use subshells which aren't lightweight and you have also to deal with the scope.
15 minutes of better than any of my books on $BASH
Tq. I appreciate the knowledge.
note that this works because the brackets are just an alias to the `test` program. Check it's man page for some more info
this is very very helpful, please fo more!
If you want to split code across multiple lines instead of using a semicolon between each command, you can do something like
condition && {
command1
command2
. . .
} || {
command3
command4
. . .
}
This has the added effect that the second block will run if the first block fails. For example, try the following: true && false || echo foo # "foo" will be echoed. Sometimes this behavior is desired, sometimes not
The && && && || example - i would hate to know/remember presence (with no braces) (even when the precedence is very efficient for that).
Thank you
if elegant means "Do as much as possible with as less code as possible", then it's ok, but someone new may be confused by some operations
Yeah, readability is important too
I agree, there are definitely uses for these ideas but the notion that you should never use "if" is ridiculous. In fact there are few circumstances in programming that one should never use.
Elegance is readability.
If statements are almost always more readable to more engineers than the things you suggest here.
biggest benefit to the "non-elegant" ifs... is people on your team, who might not yet be master-bashers, can look at (nested) ifs with less cognitive load and quickly produce a concise change/fix. also this doesn't handle elif well... what is the more elegant way of handling a condition with 4 elifs?
that's just purest art
Could you do a tutorial video on signals and traps? Please and thank you.
Thanks for this
[[ tast ]] && command_1 || command_2
This code can execute BOTH commands in some cases... If "test" is TRUE; the command_1 will execute, but if then the command_1 fails for some reason - also the command_2 will be executed. So... using IF-THEN-ELSE is not a bad idea ... it has a reason.
love these videos and the ones you made before. It inspired me to download i3 and I now have a burning hatred for Microsoft. Thanks, appreciate all your work!
I love this but you do have to be aware that if the thing after && returns with an error code it will run the thing after ||.
/bin/sh
x=0
[ x -eq 0 ] && cat /something/that/doesn't/exist || echo "x isn't 0?"
That exactly what I illustrated at the end.
So basicly, if I want an if-else-statement, I can't make do with these operators? In most such cases the command after && probably is not prone to fail but still it's not technically correctly written code if I want the real if-else-functionality, right?
@DAudIcI, so it would seem that if statement is the best option if there's a need for 'else'. More often than not it is present in my conditional needs so I'm getting a feeling that Luke might've exaggerated a bit too much claiming that (almost) never should if statement be used in a shell script.