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 💰😎👌💯 - วิทยาศาสตร์และเทคโนโลยี
![Write beautiful shell scripts with Gum! [Terminal Velocity 4]](http://i.ytimg.com/vi/tnikefEuArQ/mqdefault.jpg)
![[UNCUT] รัฐสั่งหยุดปล่อยคลื่น! แต่หยุดพลังปะทุ “น้องหญิง” ไม่ได้ I คนดังนั่งเคลียร์](http://i.ytimg.com/vi/RmQh47eIiV0/mqdefault.jpg)
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.
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.
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 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 ¯\_(ツ)_/¯
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.
Neat info. Definitely some next level bash for 90% of circumstances. Good to see you back at it, Luke.
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"
"[" 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
: ${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
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.
This video really helped me clean up some shell scripts that I have recently made. Thank you brother, and God bless
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.
Nice, I really appreciate you make those simple to novice!! Great work!!
Been looking to get bit better with my shell scripting this helped a bunch .
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.
This was really nice and enlightening. Thank you.
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.
Thank you! Was very useful!
I just jumped to a WM next up is to learn some bash scripting for fun so thanks for the new videos.
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’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
; 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? ;)
I use nested if more often these days. I think it more clearly describes my intent and makes revisiting older scripts easier.
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.
That semicolon saved me! Was using && in the wrong place, thank you.
The videos in your reboot so far have been fantastic.
; 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 :=)
Thank you for that video && especially for the last example cause logical operators really can do very special thing
Beautiful explanation, Luke!
OMG, such a simple explanation about BASH, the semi-colon, which I hate in all languages, but you've explained it so easily.
I love your videos, thank you so much for making amaaazing terminal videos
Thank you Luke !
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.
$ 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
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.
I really needed this video, time to optimize sum scripts, also in what kinda situtations you DO actually need to use the if statement
Thanks again. Huge help!
Thx man, very helpful information
RESPECT!! AMAZING VIDEO GONNA START DOING THIS
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.
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
blowin' my mind again. Great video!
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 want more of this. Thanks for sharing the wisdom.
Elegance is readability.
If statements are almost always more readable to more engineers than the things you suggest here.
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.
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?
Very nice. Thanks!
I don't regard if/then as "ugly," but there's no denying the && || approach is better.
Functional programming in shell script has never been so real and possible for me. Thank you! I learn a lot from you.
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.
Honestly lots of people complaining about obfuscation, but the #1 thing that would have improved this video for me would have been to mention that logical operators in bash must be enclosed in squiggly brackets to change order of operations!
I can already see the hundreds of newbies watching this video all collectively crying as they try to figure out why parentheses aren't working xD
Great videos, I learn a lot about bash and Linux from you. Thank you
I’ve been up to 3 in the morning losing track of my scripts. This helps keep it simple!!! 🎉🎉
wow this is super useful, even to a bloat user like myself! thanks
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.
Thanks, I have always wondered how some of these complex scripts meant. I only have been doing file manipulation using grep.
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.
That would have made many of my dumb scripts easier to write. Thanks, good teaching there!
This is how to not write an if when you actually mean 'if'. How is not writing what you mean improving readability?
Also, your example is not so much about the if-statement as it is about errorhandling. But if you are doing a video about errorhandling, then do it properly and talk about signal traps and all that kind of stuff.
I think the purpose for this is
cleaner and more sustainable code
shut up man, if anything is useless here it's your comment. Tell me, what did you bring to the table that provided anything?
I know the video gave me something, who cares about exactness. it's about getting better
Shire Grin “it’s about getting better” exactly. He was pointing out how Luke could have done better. And your comment was the only one that didn’t bring something to the table. Not to mention you were being very rude.
First, we don't know how Luke handles all these comments. If comments like this one discourage him from uploading more, which are FOR FREE by the way, then I would rather stop seeing comments like the above one, than his videos. I don't care if in your mind that comment was helpful.
Second, by the same reason it is free, I don't think you get to tell Luke how he should make his videos, or anything at all. It's not fair when you are NOT creating or providing anything.
And fuck u if you think I was rude rather than the unthankful guy above, you guys are trash
Shire Grin I haven’t heard him say it, but from what I know about him I think he’d welcome constructive criticism, which is what the original comment was.
I agree that he can upload whatever he wants, and can choose to ignore what the viewers want if he so desires, but that much is obvious.
“And fuck u if you think I’m being rude...you guys are trash” oh, the irony.
Tq. I appreciate the knowledge.
ED IS THE STANDARD TEXT EDITOR
cat is the standard text editor! :-p
EXCELLENT!!! TY!!!
awesome guide, you explained it good, Thanks A lot
I have no idea what a bash script but I knew about all of the logical operators from use in if statements ironically
Very useful info, Luke
awseome, thanks for that!
Good stuff! Thank you
Yeah, yeah, you can cut down on everything and make oneliners. If you write code like this at work, I will punch you.
Write easily readable code, so it's easy to spot your damn bug.
Yep everyone in a programming team should dumb their code down to the level of the weakest programmer - or better still the manager that thinks he can code - that way you'll get perfect, easy to read, bug free code. Of course you'll have a million lines of code, that takes a tonne of memory and runs like dog, but, ya - you can work for Microsoft :)
@@danteuk8024 It's not about dumbing it down, it's about making clearly readable code. Think the Linux kernel, not stack overflow perl one liners. I thought it was obvious, but I hope this clarified it for you.
If statements don't use more memory than chained commands, and if you're conserned about the memory usage of bash itself in your script, you're using the wrong damn language, probably due to your fear of learning about the right tool for the job.
If you write all your shit on one line, relying heavily on operator precedence, assumptions and clever tricks, you're making an unmaintainable mess. I have no need for a mess.
@@danteuk8024 That's not how it works...
that's just purest art
The quarantine isn't all too bad if we get a Luke vid everyday
That was a good one!
[[ 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.
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.
Power move: your echo statements really don't need to be quoted. Sweet!
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.
another alternative, no if necessary :)
EDITOR=${EDITOR:-nano}
Thanks for video. This reminds me some of fuctional programming concepts. Is shell functional like language?
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...
This is really amazing
Thank you
Luke, I wish I can be as confident as you.
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.
If you write scripts to automate some basic task for your work, use as many if statements as you like.
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
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?
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.
Thanks for this
Hey Luke, love your videos, can you make on about bash scripts with named args?
Thanks man! I'm really learning a lot with you. I appreciate the time you put into this videos.
this is very very helpful, please fo more!
this changed my world!
15 minutes of better than any of my books on $BASH
IMO, that "Never say if" part is very arguable. Obviously a nice fit for console oneliners, but to my mind mutt-wizard on 12:10 would be more readable with verbose if statement. Another thing is that using && and || as a conditional branching mechanism means using a side-effect of those operators implementation.
If you have 'set -e' enabled in your script, don't use 'condition && action' as a substitute for 'if condition; then action; fi'. The problem is that when 'condition' is false, the former expression will fail and cause your script to exit while the latter will keep going. I suppose you could do 'condition && action || :', but I find that somewhat kludgy so I tend to avoid it.
test -n "$EDITOR" || EDITOR=nano
to me looks more fluent and elegant than
[ -z "$EDITOR" ] && EDITOR=nano
but I got the point of the video and mostly agree
Great tutorials.
I'm with Luke on this one.