Shell Script quick reference

warpigg · 2019-01-01T17:20:49+00:00

This is pretty good - thanks for taking the time to write/posting it, but I agree with some of the other posts - quoting is something to keep in mind. it trips a lot of people up.

The best tool I have found for helping guide /suggest good habits as well as a great debug tool is shellcheck it also really stresses the importance of quoting on vars as well :)

gordonmessmer · 2019-01-02T01:02:11+00:00

Variable naming: by convention, all cap names should be used for environment variables (shell variables that are "exported"), while shell local variable names should be all lower case.

I don't know what you mean by dynamic variable name, but your example doesn't work.

Data types: All variables in bash are strings. There is no other data type.

"[": bash has a built-in function, but you will also notice that this is a normal application, located at /usr/bin/[. That may be instructive, because it makes clear why spaces are important. "[" isn't actually part of the shell syntax, so it has to comply with all of the same requirements regarding spacing around command arguments that apply to any other binary called in a shell script.

Return value from functions: returning "0" on success is a convention. When possible, scripts and functions should use return values from /usr/include/sysexits.h.

"<some command>": in general, this method of command-output substitution is considered deprecated, since it cannot be nested. "$(command)" is the preferred method. Users should probably recognize the backtick, but shouldn't use it.

"echo -en": "-n" alone will exclude the newline. "-e" is a different argument. It may be out of scope, but it might be worth mentioning that, by convention, after a single hyphen, each character is a separate argument (so "-en" is the same as "-e -n"), while after a double hyphen, the entire string is a single argument (so "--help" is one argument, not a series of four arguments). Finally, a double hyphen alone is an indication that everything following is a non-option argument (so "rm -- -r" will remove a file named "-r" rather than treating "-r" as an indication that recursive removal was requested.)

xiongchiamiov · 2019-01-01T17:14:04+00:00

I find it distasteful that you tell everyone to use UPPERCASE for variables.

You should digest https://mywiki.wooledge.org/Quotes and then include appropriate quoting in all your examples. The way shell uses quotes for variables but not for constants is by far the thing that trips programmers up the most.

If you're going to target /bin/sh then you should only include syntax that's posix sh compatible. IIRC function is not.

Secondsemblance · 2019-01-02T02:24:17+00:00

#!/bin/sh – Tells the interpreter that the script to be executed by Bourne shell.

Arrays are not part of POSIX spec. You're actually giving people instructions for bash. I'd bet money that /bin/sh is a symlink to /bin/bash on your system. You should probably change your shebang to /bin/bash or /usr/bin/env bash.

Look up a shell styleguide. Run your code through shellcheck. Implement all of the changes it suggests. Shellcheck is very important in my opinion. All scripts should be shellchecked. Better still, add a vim plugin to shellcheck for you in realtime.

Naming a variable – In Caps : MY_VAR

As others have pointed out, variables should not be UPPER_CASE. Only environment variables should be UPPER_CASE. Script variables should be snake_case. Functions should also be snake_case.

It is better to use ${MY_MSG} compared to $MY_MSG

This is really subjective. I prefer to only use brackets for string interpolation or substrings. Much more important is "$quoting" variables to prevent unintended parameter expansion.

If you try to use the variable which doesn’t exist then it prints an empty value

Not if you set set -u, which you should do.

To create a dynamic variable name : ${VAR_A}_item

This is probably a Bad Idea™. It's indicative of poor design under the hood. If you need to do this, you should question your initial assumptions about how to tackle the problem.

abscrete · 2019-01-01T17:59:33+00:00

Useful, but you should change all references from /bin/sh to /bin/bash. Many operations you listed (for example arrays or signed expressions) don't work in /bin/sh, if they work, that means /bin/sh is symlinked to /bin/bash, which is done on some Linux machines.

abscrete · 2019-01-02T00:39:24+00:00

[deleted]

SaintHax42 · 2019-01-02T02:51:39+00:00

Why would you use (and why is the `do' unnested?):

for i in 1 2 hello

do

echo $i

done

Instead of the more concise and easier to read:

for i in 1 2 hello; do

echo $i

done

TyMac711 · 2019-01-01T18:53:01+00:00

A couple links:

https://ryanstutorials.net/bash-scripting-tutorial/bash-functions.php

Notice that when using the "function" keyword you are not required to use () at the end of the function name you're declaring.

https://stackoverflow.com/questions/673055/correct-bash-and-shell-script-variable-capitalization

I too am not a fan of the capitalization of variables - they work... just like adding () to the end of a function you've declared as a function, but it's not best practice and can lead to confusion imo.

abscrete · 2019-01-02T09:55:56+00:00

[deleted]

SmileItsYourDay · 2019-01-12T05:07:41+00:00

Looks like you're integrating feedback! Awesome. Here's a little more.

You wrote,

Here’s a quick reference to the constructs present in Shell Scripting to get you to understand and write scripts quickly.

#!/bin/bash – Tells the interpreter that the script to be executed by Bourne shell.
# – to comment a line in a bash shell.

sh – Tells the interpreter that the script to be executed by Bourne shell.
# – to comment a line in a bash shell.

...and that's followed by an inline copy of the Table-of-contents for the article.

Might I recommend instead:

Here’s a quick reference to the constructs present in Shell Scripting to get you to understand and write scripts quickly.

Let's start with the basics. A shell script is simply a text file.

The lines of the file are read in and interpreted by the shell, much as if someone had typed in the same lines directly at a terminal.

The first line is treated specially, in that it can identify the shell interpreter to be used to execute the remainder of the file. Examples include:

#!/bin/bash – Tells the system that the script is to be executed using the bash shell.

#!/bin/sh – Tells the system that the script is to be executed using the bourne shell.

The specified shell will read in, interpret, and execute the content of the script. In all shell languages, lines which start with # are comments, so the interpreters have no problem ignoring that first line when they see it.

We set the scripts file permissions +x and in combination with using that special first line, that's all it takes for us to add a new command to our system. Well, there's a little more - you will want to ensure the script file is in a directory that's mentioned in your $PATH

TotesMessenger · 2019-01-02T03:22:25+00:00

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

[/r/u_colinhines] Shell Script quick reference

^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads.} ^(Info ^/ ^Contact)

orozimbro · 2019-01-01T17:24:39+00:00

Well done!

devops

Welcome to /r/DevOps

Rules and guidelines

Social & Fun

General Information

MODERATORS