Dissecting Bash Scripts

tknomanzr · 2016-03-11 21:52:50

As said, return codes can vary, depending on the program.

I wanted to point out a basic understanding of && and ||. && is logical and, which only returns true if both sides of a comparison return true. || is logical or and will return true if one or more sides of a comparison return true. ! or logical not reverses the logic. Consequently, it can be derived that if any portion of a logical && returns false, then the entire statement returns false, so the interpreter can safely stop processing the logic. Similarly, if any portion of a logical or returns true then the entire statement is considered to be true as well. This allows for performance speedups, not having to process superfluous logical tests. Given this, sometimes, the way you structure your program logic can make a considerable difference.

Also, I wanted to point out a small trick that I use when coding in a language I am less familiar with and that is the idea of testing units. The easiest way to set this up is to start echoing variables out to the terminal. Check inputs, then check outputs. This allows you to answer several important questions: 1. Am I getting the input I am expecting? 2. Am I getting the output I am expecting based on the input? 3. If I am not getting expected output, what went wrong? Is it an error in logic? In the case of shell scripting am I using proper shell escapes? (This one gets me big time). If processing arrays or other complex structures, are they coming to me in a way that is recognizable and easily processable? Or do they need further processing in order to get more structured data? The point here is, the liberal use of echo, print, whatever the language uses to output to the screen, don't be afraid to use it to test things when you are learning and/or building. Also, this lets you build and test smaller units of code without necessarily having to have some grand vision of what a complex piece of code needs to look like. As long as you have a good idea what the inputs and outputs of a given function should look like, it becomes quite easy to build code as a series of smaller building blocks which you later hook together via a main function (in the case of a functional driven piece of code) or method (if building it object-oriented.). Of course, it makes sense to remove all the extra cruft once you feel a program is fairly stable and ready to publish.

johnraff · 2016-03-12 00:07:03

tknomanzr wrote:

I wanted to point out a basic understanding of && and ||. && is logical and, which only returns true if both sides of a comparison return true. || is logical or and will return true if one or more sides of a comparison return true.

While true in general, in shell scripting I think this way of understanding it can cause confusion. What I find easier to grasp is the idea that && and || link commands, in a similar way to ; and &.

&&

If the last executed command returned 0 (success) then execute the following command.

||

If the last executed command returned non-zero (failure) then execute the following command.

NB In more complex logic flow, the "last executed command" is not always immediately to the left of the && or ||.

This is how 'man bash', for example, talks about logical tests and once you've got it it does make things simpler.

So in shell scripts "if" is working like this:

if <command returns 0>; then <execute other command>;fi

It's NOT
"if <condition is satisfied>; then..."

Even [ for example, is a command which returns success or failure. (It's an alias of 'test'.)
Only the [[ ]] syntax is different, being an import from other language usage.

Horizon_Brave · 2016-03-18 22:00:04

Wow, I could have *sworn* I responded to this, giving my normal thanks of everyone's responses.

So in shell scripts "if" is working like this:
if <command returns 0>; then <execute other command>;fi
It's NOT
"if <condition is satisfied>; then..."

That portion is what always throws me off.

Also, I wanted to point out a small trick that I use when coding in a language I am less familiar with and that is the idea of testing units. The easiest way to set this up is to start echoing variables out to the terminal. Check inputs, then check outputs. This allows you to answer several important questions: 1. Am I getting the input I am expecting? 2. Am I getting the output I am expecting based on the input? 3. If I am not getting expected output, what went wrong?

Great idea tkno!! Even when reading other people's scripts, I can make a very similar copy and see the output for the return status and logic etc..

#21 2016-03-11 21:52:50

Re: Dissecting Bash Scripts

#22 2016-03-12 00:07:03

Re: Dissecting Bash Scripts

#23 2016-03-18 22:00:04

Re: Dissecting Bash Scripts

Board footer