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

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 💰😎👌💯

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

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

[@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 ¯\_(ツ)_/¯

[@flarone]

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

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

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

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

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

[@0hhtecMusicianTheNotecianHero]

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

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

[@Raatcharch]

The videos in your reboot so far have been fantastic.

[@kirk0831]

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

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

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

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

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

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

[@JKhalaf]

This was really nice and enlightening. Thank you.

[@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 :=)

[@nekomantia]

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

[@bitcointrader8586]

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

[@antonlee0]

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

[@overclucker]

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

[@Ray_TambaBudol_Marcos]

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?

[@metasavagex]

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

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

[@musclesmouse]

Thanks, I have always wondered how some of these complex scripts meant. I only have been doing file manipulation using grep.

[@zcalex7660]

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

[@user-mr8ij8gi7c]

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.

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

[@cepi24]

Thanks for video. This reminds me some of fuctional programming concepts. Is shell functional like language?

[@GlebEagle]

Thank you! Was very useful!

[@Pray4ragE]

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

[@DennisChaves]

blowin' my mind again. Great video!

[@johanfer]

Thanks man! I'm really learning a lot with you. I appreciate the time you put into this videos.

[@drewberchtolzthofen886]

Beautiful explanation, Luke!

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

[@Shineylake]

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

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

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

[@pnddesign]

Thank you Luke !

[@PianoShawn]

Thx man, very helpful information

[@JohnMatthew1]

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

[@MB-up3mh]

Hey Luke, love your videos, can you make on about bash scripts with named args?

[@jasons1856]

Thanks again. Huge help!

[@waseemqaffaf5715]

RESPECT!! AMAZING VIDEO GONNA START DOING THIS

[@dragangolic6515]

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

[@MarcoDamaceno]

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

[@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? ;)

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.

[@lemler3337]

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

[@jessegodsey]

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

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

[@kryzoxy1]

I see more elegant and readable an if structure, maybe i am to used to it. But the block structures are made for a fast comprehension of the code.

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

[@berkpwn]

Putting & at the end of any command just starts it in the background. Run fg to bring it back to the terminal.

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

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

[@berndeckenfels]

The && && && || example - i would hate to know/remember presence (with no braces) (even when the precedence is very efficient for that).

[@wesg01]

Very nice. Thanks!

[@sergeynaruzhiny7422]

awesome guide, you explained it good, Thanks A lot

[@jackoberto01]

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

[@CarloPiana]

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

[@apolloapostolos5127]

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

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

[@Filaxsan]

Very useful info, Luke

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

[@AnthonyP2A]

EXCELLENT!!! TY!!!

[@JohnNagleIV]

Could you do a tutorial video on signals and traps? Please and thank you.

[@vilks_jan]

Good stuff! Thank you

[@lahzy7851]

So does shorter more efficiant code equal to faster running software? Is this what people refer to when they for example say a game is badly optimized? When it takes the computer longer to get to the result because of unnecessary extra steps?

[@kychemclass5850]

Tq. I appreciate the knowledge.

[@malix31]

Hi Luke , thank you for your video , you r right we don’t see your video but we use utube-dl to check them offline ;) . Nice tip to replace if statements , I check the default .bashrc of Debian dist there r if statements . I understand it’s for more readability.how do u you I interprète this

[@ensomniac]

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

[@KipIngram]

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

[@PJBrunet]

To span multiple lines... would it be [ condition ] && \ doit && \ dothistoo

[@marco201ful]

I am new to this channel can someone tell me what Desktop Environment he is using? I have hunch of this being tiles?

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

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

[@zbiqu23]

awseome, thanks for that!

[@neonblood4658]

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

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

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

[@boori9557]

Luke, I wish I can be as confident as you.

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

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

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

[@jeep2liberty]

"Elegant" ?? more compact perhaps, but &&, || are , not the same as if then (else) fi. I can see his point on being easier to read however. Thanks for the video.

[@soufianta8374]

Hi there. Is bash scripting a good way to start programming or do I have to spent my time to learn ruby or python (for system administration tasks)? Thanks ..

[@helpme2999]

I'm going to be honest, its very rare that I see people outside of Japan or Eastern Europe for some reason using Ruby for anything.

[@yash1152]

2:56 ahw, so, the "shortcircuiting" of logic applies here as well, C language does this shortcuiting too

[@kerbrose]

This is really amazing

[@jordanstewart225]

Hey Luke, Great video, i'm interested to know: Have you thought about streaming on twitch.tv? thanks

[@NunoLeitaonunogrl]

another alternative, no if necessary :) EDITOR=${EDITOR:-nano}

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

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

[@marcin6386]

That was a good one!

[@RonnyOlufsen]

Good job explaining! I am an old ninja, but I learn stuff and I enjoy these videos as nerdtainment

[@PlamenDimitrov-ks2cl]

If you write scripts to automate some basic task for your work, use as many if statements as you like.

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