Never say "If" writing a Bash script! (Exit codes & logical operators)

[@hmagellanlinux307]

Boomer avoids the stress of the apocalypse by obfuscating his bash scripts

[@stdcall]

Are you guys ready for the boog?

[@superscatboy]

I'm gonna go and strip all the newlines out of my C++ code and see if it makes me feel better about myself.

[@LaughingOrange]

@@superscatboy It could make the file smaller.

[@superscatboy]

@@LaughingOrange Lol yep I've been meaning to free up a kb or two of disk space ;)

[@tomaszubiri4588]

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.

[@jaimesotelo4252]

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.

[@sameer26121980]

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.

[@alexanderelgert6037]

Yes, you are right, we should give Luke a few hints: $ false && echo hello && echo ok $ if false; then echo hello; fi && echo ok

[@Cypekeh]

@@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

[@sadface7457]

Terry Davis always said that the CASE statement was divine

[@sadface7457]

Lisperati know when not if.

[@btschaegg]

On that note: I wonder if there is a way of building a Duff's Device in Bash.

[@timh.6872]

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.

[@nicolareiman9687]

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 .

[@lawrencedoliveiro9104]

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.

[@bwcbiz]

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"

[@jeetadityachatterjee6995]

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

[@robrick9361]

@@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.

[@ChrisCox-wv7oo]

@@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

[@geoffl]

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

[@ChrisCox-wv7oo]

@Evan John Programming ¯\_(ツ)_/¯

[@kashnomo]

It's worth noting that Luke uses these compact forms in a way that makes his code more legible.

[@homelessrobot]

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.

[@protoketer4554]

yup, the code example he showed was much easier to read than the large if-blocks that I have been guilty of writing lol

[@DimitriSabadie]

I hope people don’t listen to this too seriously.

[@m0gria]

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!

[@incrediblygay]

So, only statements should be used when doing this?

[@erdanxiloscient3666]

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

[@Semaley]

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.

[@flarone]

Neat info. Definitely some next level bash for 90% of circumstances. Good to see you back at it, Luke.

[@nilsirl]

"[" is a command (it more or less aliases to "test"). So when you do `[ -z "$EDITOR" ] && do_smth`, the if is not technically implicit.

[@loarto]

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

[@fuseteam]

🤯

[@PhilippeCarphin]

@@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.

[@loarto]

@@techtutorvideos you don't even have to have the ; :D

[@josephsmy1994]

interesting

[@m0gria]

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.

[@countdigi]

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"

[@PacAnimal]

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.

[@danteuk8024]

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 :)

[@PacAnimal]

@@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.

[@Monk-E]

@@danteuk8024 That's not how it works...

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.

[@davocc2405]

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.

[@v0ldelord]

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.

[@Kor1134]

Looks clean to me. I write my scripts like this, _"if/then/else/fi"_ and _"command && {…} || {…}"_ look functionally identical to me.

[@MatthewDeVore]

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.

[@MatthewDeVore]

@ Actually, looks like I was wrong about this. foo && bar won't terminate the script if "foo" fails in set -e mode. Sorry!

[@PhilippeCarphin]

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.

[@MatthewDeVore]

​@@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.

[@PhilippeCarphin]

@@MatthewDeVore One of the lesser known "features" of Bash.

[@MatthewDeVore]

@@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.

[@peterbonnema8913]

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.

[@landro3552]

I think the purpose for this is cleaner and more sustainable code

[@shire7949]

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

[@electric26]

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.

[@shire7949]

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

[@electric26]

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.

[@yash1152]

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.

[@nicholasgulachek8421]

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!

[@MarcoDamaceno]

Functional programming in shell script has never been so real and possible for me. Thank you! I learn a lot from you.

[@JohnMatthew1]

OMG, such a simple explanation about BASH, the semi-colon, which I hate in all languages, but you've explained it so easily.

[@loarto]

; 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.

[@lawrencedoliveiro9104]

Do you get the feeling that Bash syntax has, shall we say, evolved by accretion over time? ;)

[@johseh5312]

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.

[@berndeckenfels]

; 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 :=)

[@Pabloparsil]

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.

[@y00t00b3r]

oh my god, I'm bowled over by Luke's discovery of the statement terminator token.

[@con-f-use]

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.

[@kaihendry]

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.

[@shirgar4390]

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

[@CottidaeSEA]

@ 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.

[@daggawagga]

The ] is a lie

[@0hhtecMusicianTheNotecianHero]

This video really helped me clean up some shell scripts that I have recently made. Thank you brother, and God bless

[@Cranked1]

Code quality is one of the most important things and by doing "shorter" "more elegant" code, you'll loose on code quality. This is not good advice. If you're searching for a bug in your bash script and you're checking all the "if" statements, then this would be a horrible way to tell apart normal script from an indented if statement. Why aren't you doing everthing in one line? Would be more elegant, or wouldn't it?

[@Slashx92]

In my opinion, less code is less bugs. But I make the compromise when things are unreadable , or the cognitive overhead of scanning the code is heavy IMO. If I'm writing 5 simple if statements, vs 5 implicit condition evaluations, the shorter way will always be more elegant. In the other hand, if I'm evaluating nasty nested conditions, with if/ifelse/elses . Maybe a shorhand will make more harm that good. And in those cases is common that I encounter a way of refactor to those complex flows

[@SimGunther]

Instructions unclear; ended up with a plan 9 emulator in a bash script.

[@nerrufam7105]

🥂, you reminded me of the classic: Instructions unclear, d!ck stuck in fan.

[@BillSteinhauser]

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.

[@alexanderelgert6037]

$ 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.

[@philpeko1796]

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

[@paolo_in_corsivo]

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

[@Raatcharch]

The videos in your reboot so far have been fantastic.

[@BrunoBeltran]

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

[@JonathanNelson-nelsonj3]

These are great IF you need a single line command. However, when writing an application in Bash please use the expanded syntax as they are easier to read and understand.

[@apolloapostolos5127]

I’ve been up to 3 in the morning losing track of my scripts. This helps keep it simple!!! 🎉🎉

[@overclucker]

I use nested if more often these days. I think it more clearly describes my intent and makes revisiting older scripts easier.

[@a_maxed_out_handle_of_30_chars]

Corona-chan is helping me learn bash script :)

[@zvezdan956]

@@robertkiestov3734 Unironically true and based.

[@gayusschwulius8490]

@@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.

[@eduardoantunes2958]

@@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.

[@drygordspellweaver8761]

More people have died of the “vaccine” than the virtual coof.

[@zvezdan956]

@@gayusschwulius8490 just because u had a cough doesnt prove the existence of a pandemic. u r brainwashed, seriously.

[@vaughngx4]

That semicolon saved me! Was using && in the wrong place, thank you.

[@xseman]

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

[@Yautjaprime]

Yeah, readability is important too

[@michaelgrubb3508]

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.

[@distributedsystemsfanboy5208]

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.

[@antonlee0]

I want more of this. Thanks for sharing the wisdom.

[@zss123456789]

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?

[@kirk0831]

Nice, I really appreciate you make those simple to novice!! Great work!!

[@HarryJarrell]

I understand what you are saying, but if you want to have a script with many branches, then you will need to use if statements.

[@Linuxdirk]

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.

[@damirahman]

less readable and fewer keywords =/= elegant

[@rodrigosouto9502]

I'm with Luke on this one.

[@dr.mikeybee]

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.

[@SzymonDatko]

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.

[@Simon-yf7fo]

I think the biggest problem of bash isn't code like this. What your students mean by bash is a ungly language is most likely not this as this isn't even close to the majority of the bash code. The problem also isn't the 3 lines really, but rather that you can write an if in like 3 or 4 different ways and every one of them act differently. My experience in bash compared to any other language is that it just feels WAY less consistent how it interprets what the programmer wrote.

[@bitcointrader8586]

Been looking to get bit better with my shell scripting this helped a bunch .

[@xander-on-the-earth]

I disagree. The ‛if’ construction is not the same as the logic operators possibly surrounded by parentheses or curly braces. I’m not sure about Bash, since I always use ‛/bin/sh’ in the shebang, but in Dash and then probably in all POSIX shells, these syntax constructions have principally different meanings. If you use the ‛set -e’ option to turn errors into some kind of exceptions, which should stop the script on the very first unprocessed error , the ‛if’ (and analogous syntax constructions like ‛while’ etc.) are considered as error handling, so the script won’t be interrupted if the command tested has just returned some non zero exit code. On the contrary, the stand-alone logic operators - ‛&&’, “||` - are not considered by the shell as an error handling route, thus the script will be interrupted anyway if the command tested like this has not succeeded despite what you wrote inside the logic operators. Thanks Luke for the channel, I like it, and forgive me this little criticism!

[@lemler3337]

wow this is super useful, even to a bloat user like myself! thanks

[@JethroYSCao]

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.

[@yash1152]

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.

[@wouldbabyhitlerkillyou4217]

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.

[@lukevideckis2260]

if [a] b elif [c] d else e becomes ([a]&&b||true)||([c]&&d||true)||e||true

[@stnsls]

: ${EDITOR:=nano}

[@ba-a-a]

And how in the name of fuck is this sorcery called? I'm looking for googleable name.

[@bartolomeykant]

But if I export EDITOR="" it will works the same way?

[@btschaegg]

@@ba-a-a www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html

[@desubakadesu]

@@bartolomeykant Yep

[@desubakadesu]

echo "export EDITOR=nvim" >> ~/.zshrc echo "export EDITOR=nano" >> ~/.zshrc echo "export EDITOR=nvim" >> ~/.bashrc echo "export EDITOR=nano" >> ~/.bashrc

[@jackoberto01]

I have no idea what a bash script but I knew about all of the logical operators from use in if statements ironically

[@windowsrefund]

Power move: your echo statements really don't need to be quoted. Sweet!

[@cfd6577]

Ah bash... The only time that clean, readable code is discouraged in favor of garbled, concise statements to save 'line space'.

[@Chemaclass]

bashunit is key to make sure your logic works as expected 😊

[@vldthdrgn]

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?"

[@LukeSmithxyz]

That exactly what I illustrated at the end.

[@Fetusgi]

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?

[@Fetusgi]

​@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.

[@CarloPiana]

That would have made many of my dumb scripts easier to write. Thanks, good teaching there!

[@KipIngram]

I don't regard if/then as "ugly," but there's no denying the && || approach is better.

[@nekomantia]

Thank you for that video && especially for the last example cause logical operators really can do very special thing

[@wjckc79]

15 minutes of better than any of my books on $BASH

[@davidrihtarsic2615]

[[ 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.

[@Arcticpagan]

I just jumped to a WM next up is to learn some bash scripting for fun so thanks for the new videos.

[@hersenbeuker]

ED IS THE STANDARD TEXT EDITOR

[@readmelast]

cat is the standard text editor! :-p

[@neonblood4658]

The quarantine isn't all too bad if we get a Luke vid everyday

[@bluesquare23]

If I cared about elegance I wouldn't be writing bash

[@bluesquare23]

I actually went on and updated a script after seeing this. It takes some getting used to but it’s pretty cool actually. Thanks Luke.

[@bluesquare23]

This video keeps getting more and more useful as time goes on

[@GlebEagle]

Thank you! Was very useful!

[@ensomniac]

Elegance is readability. If statements are almost always more readable to more engineers than the things you suggest here.

[@AtomToast]

note that this works because the brackets are just an alias to the `test` program. Check it's man page for some more info

[@edvonrattlehead2135]

I really needed this video, time to optimize sum scripts, also in what kinda situtations you DO actually need to use the if statement

[@ertwro]

Sometimes only using operators is better but "if...then...else...fi" is not equivalent to "...&&...||..." In the if statement you wouldn't execute the or command if the first command failed. Although, you could do the same by adding parenthesis and grouping the second and third operation.

[@jakob1379]

shoot. Have rewrite everything I ever made now. But I couldn't agree more! This looks so much better and makes the workflow of bash more fluent.

[@-morrow]

your example could be simplified to: echo ${EDITOR:-nano} edit: only for bash

[@Kor1134]

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_ _}_

[@Kor1134]

@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.

[@shire7949]

Very interesting thanks. I wish less people used your videos just to get a chance to comment a dumb joke

[@JKhalaf]

This was really nice and enlightening. Thank you.

[@pokefreak2112]

You kinda sound like the average javascript programmer advocating for ternary statements and map() over if and loops not gonna lie 👀

[@timh.6872]

If you set things up right, functional programming inspired patterns can often link syntax to meaning much more tightly. The step _after_ map for for loops and if statements is python comprehensions: filtered for loops as expressions. They're a bit weird at first, bit once you get the hang of them they're so beautiful.

[@pokefreak2112]

@@timh.6872 Yeah I'm with you, I also prefer data driven/functional code over procedural/oo. I just think it's funny for luke to talk about writing elegant code when his linux setup is all about function over form

[@timh.6872]

@@pokefreak2112 In the right context, function is form. That is, code can be beautiful and elegant because it does what it needs to and only what it needs to. In the cases he shows here, 'if' is completely superflous, and so by making it work better, it is also more beautiful.

[@NuncNuncNuncNunc]

So true. I prefer poring over a dozen lines of code to figure out what a loop is supposed to do instead of reading the name that tells me what it does. People who can't read a ternary confuse me. It's only three expressions and no need to create a non-const variable.

[@cheesits456]

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 . . . }

[@samgould8567]

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

[@zulowski]

LoL, as a developer I hate when reading colleagues code with if/else statements... I try to teach them how to avoid them... and now You with this Video.... ;-)

[@lordseaworth6055]

The if codes are much better when working with other people. It is much cleaner and documented.

[@drewberchtolzthofen886]

Beautiful explanation, Luke!

[@andrasfogarasi5014]

yeah well you can do this in c++ too it's just that people will hate you for it

[@dragangolic6515]

Great videos, I learn a lot about bash and Linux from you. Thank you

[@ertaiblue9815]

Luke Smith's brain just won't fit in the camera window.

[@monad_tcp]

0:25 IF considered harmful !

[@samgould8567]

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.

[@artadams1]

At some point in your childhood, you and your friends went outside to play together for the last time, and none of you knew it

[@geiger21]

oh god, that is deep, but it's true.

[@randomcontrol]

I think the goal should not be to write scripts “Shell-like” but easy to read and understand. Scripts that are incredibly easy to understand are the real elegant ones.

[@Robert-qw3lr]

the bash ifs I use are always for checking the input params at the top of a script.

[@orthodoxNPC]

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?

[@thechillhacker]

Most of the time I have preferred sexplicit if/else junk over ternary and boolean operators only if to appease a smoothbrain boss who can't really read code.

[@zacklee5787]

&& and || seem better suited for quick one-liners in the command line. Using them in actual scripts may seem "clever", but when you're trying to figure out what your chain of 12 logical operators is supposed to do a month after writing it, you may have some trouble.

[@iShredStreets]

Well yeah, that's nice but I just want my Terminal to have cool colours like that.

[@mattwilliams1844]

So basically what Luke is trying to say is learn boolean algebra aka intro to discrete mathematics, and you will better understand how to write more elegant code, in general , not just shell scripts

[@mattwilliams1844]

@K F I disagree, boolean algebra makes this concept easier when writing code, it carries over to all languages, it is general-purpose, it even carries over to the basics of formulating logical arguments. It is the basics of how computer circuit gates function. Demorgans law etc. Indeed it is a requirement for most if not all Comp Sci degrees, which does make sense, it is one of the simple beginner concepts that seperates a programmer from the modern day "developer" or boot camp brainlet.

[@metasavagex]

I love your videos, thank you so much for making amaaazing terminal videos

[@xephael3485]

2:30 you should explain why the \ is needed before the! in "General Kenobi\!"

[@philpeko1796]

What? Wait, no, actually! @ Luke Smith was worng, there is no need for escaping this "!" character between double-quotes. (That may have been your ironical point?). It seems Luke does not know it.