DEV Community

Bash from scratch: learn enough bash to write your own scripts

Ahmed Musallam on September 10, 2018

You should probably read @maxwell_dev's post: The Shell Introduction I Wish I Had before this I find myself always needing to write shell script...

Read full post

Erebos Manannán • Sep 11 '18

#!/usr/bin/env sh

You might want to consider replacing sh with bash if you want to actually do BASH scripting. They are different interpreters, and one can lead to vastly different set of available features depending on platform you run it on, while the other will (correctly) crash if the missing features (namely BASH) is missing on the system.

Ahmed Musallam • Sep 11 '18

I started this post to talk about shell scripting in general. but I think I think you’re right, its confusing that way. I’ll change the shebang to be bash exclusive. Thank you for the feedback!

Erebos Manannán • Sep 11 '18

Both are definitely valid options, just if you want to write for bash then it's better to avoid ambiguity about it. When writing with support for BSD, Busybox, etc. environments in mind (e.g. inside Alpine Linux), sh is the better option, just comes with some extra baggage.

Erebos Manannán • Sep 11 '18 • Edited

Instead of referring to some online articles on test conditions, you can just check out man test.

Conditions and most other such things are good to shorthand a bit, and if you're planning on using BASH use [[ ... ]] instead of [ ... ] as they also function differently. Stick to one style for predictability. serverfault.com/a/52050

Slightly compacted formats

if [[ "$FOO" == "1" ]]; then
  ...
else
  ...
fi

for i in 1 2 3 4; do
  echo $i
done

while [[ true ]]; do
  ...
done

Also shellcheck.net/ is an excellent resource to use to check your scripts for common bugs etc. There's even a decent unit testing framework for BASH scripts nowadays: github.com/sstephenson/bats

Ahmed Musallam • Sep 11 '18

This is fantastic! I’m still new to bash scripting :) but will include this in the article. Great feedback!!

Ahmed Musallam • Sep 11 '18

I have updated the post, thank you again for the feedback!

Brad Robertson • Sep 12 '18

Excellent article, and very helpful comment discussions as well! The concise descriptions with supporting examples makes it a quick and effective read.

Anyway, wish I had read an article like this 9 months ago-- the information about shift, loops and functions would have gone a long way in the scripts I've been writing to provision our Ubuntu Vagrant VMs for use as localhost web dev environments.

Looking forward to applying some of this. Thx for posting!

Erebos Manannán • Sep 12 '18

Just as a quick comment - you should check out actual provisioning tools, such as SaltStack and Ansible if you want reproducible environments (or event driven infrastructure actions, secret management, easily distributable remote command execution, etc. etc.)

Ahmed Musallam • Sep 12 '18

Glad you liked it! Honestly, I wrote it after struggling with bash for a few weeks. I was copying and pasting things I did not understand exactly how they worked.. mainly that while-shift loop.

Erebos Manannán • Sep 11 '18

Oh, another thing I just noticed. Generally people like to think "eval is evil", and while imo eval has it's place, especially in BASH, you can avoid using eval with various tricks.

JAVA=$(which java)
APP=$1
EXTRA=""
if [[ "$NEED_EXTRA" == "1" ]]; then
  EXTRA="--extra arg"
fi

"$JAVA" "$APP" $EXTRA

It's got a lot to do with how variable expansion and quoting works.

So in your specific example

COMMAND="mvn clean install -P$PROFILE -Dcrx.user=$USER -Dcrx.password=$PASSWORD"

eval $COMMAND

I would instead write that as

PROFILE="${PROFILE:-autoInstallPackage}"
USER="${USER:-user1}"
PASSWORD="${PASSWORD:-pass1}"
mvn clean install "-P$PROFILE" "-Dcrx.user=$USER" "-Dcrx.password=$PASSWORD"

Ahmed Musallam • Sep 11 '18

I agree with you that eval, in most languages is viewed as evil. But that's largely because it might be used in applications with a lot of end users, where it is possible for something malicious to happen.

In this case, and for bash, the scripts are for productivity where you (the developer) or your immediate team are the one's running them and they are not meant for production applications.

Overall, I think it is worth pointing that out in the post :)

Max Antonucci • Sep 12 '18

Aww thank you so much for the shout-out in the start! This looks like a great post as well, I've got it on my list to look through in more detail and take notes on the most useful scripts and commands :)

Ahmed Musallam • Sep 12 '18

you got it! yours was an excellent read :)

Mohamed Hussain • Sep 21 '18

Thanks Ahmed for this concsice article covers shell scripting essentials which will help in writingand understanding the bash file...my doubt is 1. Do we need to use only the uppercase for the variable?....2. what is the difference between the sh and bash ..what is default in Mac terminal....

Ahmed Musallam • Sep 21 '18 • Edited

Hey, Glad you liked it!

Using uppercase variable names is a naming convention you'll see in most scripts out there. You can chose a different convention :) nothing is stopping you :)
sh stands for shell. bash is a shell. Read @maxwell_dev's post at the beginning of the article.

Ben Sinclair • Jan 7 '19

Using uppercase is a convention for variables from the parent environment. Lowercase for variables that are local to our script.
I see people use uppercase all the time, but it's usually just because a lot of scripts don't need local variables and that's how they learnt.
I mean, it doesn't really matter... but I am the cheerleader for Team Lowercase.