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

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.

Terry Davis always said that the CASE statement was divine

You can group expressions with curly brackets: { command1 || command2 ;} && { command3 || command4 ;} Or more complex. The brackets also make it easier to understand the code IMHO. BUT what you call elegant I call ugly and bad readability. I use this in my code but at least I don’t claim it to be beautiful or elegant. You got a negative from me today.

You and I have different definitions of "elegance". I can understand your preference for concise code, which is the traditional spirit of Unix/Linux. I, on the other hand, want my code to be readable by newbs in a corporate environment long after I've gone. I don't really consider your examples obscure for someone who has knowledge of bash, but using structures (like if statements) that are recognizable to users of other programming languages with no training in bash is also "elegant"

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

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

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!

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.

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.

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.

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

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.

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.

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

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.

The videos in your reboot so far have been fantastic.

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

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

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

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

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

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.

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

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

This video was actually helpful to me: Now I know to not use "&&" all the time. I used to think that that was required to guarantee that a command only starts after the previous one executes, but actually ";" does that as well. So I'll do exactly the opposite of what you suggested from now on. Because using "&&" actually just tells the console to evaluate a condition and then to not do anything with it. And evaluating that condition has "side effects", which are the actual commands you want to run. That is certainly not intended.

: ${EDITOR:=nano}

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

This was really nice and enlightening. Thank you.

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

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.

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.

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

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.

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

the & character puts the job in the background. The number before the process id is the job number. fg 1 would bring it back into the foreground. jobs will list background jobs and their job numbers. Cntrl z will put a running job into the background, and kill %1 will kill job #1, etc.

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

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

less readable and fewer keywords =/= elegant

Thank you! Was very useful!

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

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?

Thank you Luke !

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

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

To check if $VAR is unset, and give it a default value like <a href="#" class="seekto" data-time="660">11:00</a> 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.

blowin' my mind again. Great video!

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

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

Thx man, very helpful information

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

Beautiful explanation, Luke!

Thanks again. Huge help!

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

RESPECT!! AMAZING VIDEO GONNA START DOING THIS

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

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

IF encourages fragile, inflexible, overly specialized programs(any programming language). IF reduces performance. IF exhibits a maintenance problem that grows exponentially, doubling and redoubling the program state space. Rather, think in terms of full case/switch statements. Inform your data models so that they naturally flow each of the different possible input values and program states into an intuitive, useful state.

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.

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

I'm with Luke on this one.

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 nice. Thanks!

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.

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

Very useful info, Luke

Tq. I appreciate the knowledge.

Corona-chan is helping me learn bash script :)

that's just purest art

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.

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

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

Good stuff! Thank you

awseome, thanks for that!

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

pipefail in bash also helps reducing if, ands.

ED IS THE STANDARD TEXT EDITOR

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

Great tutorials.

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

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

this changed my world!

This is really amazing

Thank you for share!

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

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

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.

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

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.

Thank you

EXCELLENT!!! TY!!!

this is very very helpful, please fo more!

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

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