DEV Community

Shellscripting

Darkø Tasevski on August 13, 2018

Variables and Shebang Small intro to shell programming The Shell is the standard interface to every Unix and Linux syste...
Collapse
 
moopet profile image
Ben Sinclair

by convention, variable names should be all in uppercase.

A lot of scripts do that, so you could call it a convention, but generally you should only use ALL_CAPS_NAMES for environment variables or other stuff that's part of the shell's world. Variables local to scripts should be lower_snake_case to avoid collisions and hint that they're not going to have any effects outside the script.

Collapse
 
puritanic profile image
Darkø Tasevski

That sounds reasonable, thanks for the tip!

Collapse
 
puritanic profile image
Darkø Tasevski

Yeah, I would agree that setting zsh as default shell would be a bad idea, it's here just for example purposes.

On the other hand, I've already encountered an issue when I've set shebang to be /bin/sh and after googling for a while I've found that preferred shell for scripts should be bash as basically bash is sh, but with more features and better syntax.
So, I would say that:

#!/usr/bin/env bash

is maybe a better solution.

source

Collapse
 
sqlsith profile image
Chris Leonard

Good article! One comment: you should quote your variables, like this: "${myvar}". Google "bash quoted variables" for lots of discussion on this topic.

As an aside, unless I'm distributing something where I know someone might not have bash, I think it's fine to use bash for scripts. For example, everyone at work should have bash installed, so if I'm scripting there, I'll use bash. If it's intended for Linux and not Unix, I'll use bash, and let people either translate it or temporarily install bash if they don't have it installed for some reason (I think they should - it's a de facto community standard). I even installed bash on my router because not having its extensions was driving me insane.

But that's just me ... YMMV.

Collapse
 
puritanic profile image
Darkø Tasevski • Edited

Thanks! I thought that only variables without curly braces should be wrapped in quotes. I'll update the article later to include this, thanks for the advice.

I agree on using bash for #! as most of my scripts, for now, are just for mine own usage, and I guess that all my friends at least have the bash shell on theirs PC-s if not actively using it.

Another thing that I've noticed is that with #! /bin/bash, if the user doesn't have it installed, the error will be something like: cannot find command: /bin/bash and the user can install it in mere minutes instead of getting a cryptic message I got because of using #! /bin/sh when I've experimented with shell functions and spent another 15 minutes trying to resolve the issue.

Shellscripts that will be used in production env, it may be a bit better to use #! /bin/sh but that can fail too, so there is no right answer I guess.

Collapse
 
polyluxus profile image
Martin Schwarzer

If you're using #! /bin/sh you have to be POSIX compliant, otherwise you might destroy something along the way, because you cannot know what shell you are running on.
If you are relying on bash built-in, obviously you have to specify that, otherwise you might again destroy stuff.

Collapse
 
sqlsith profile image
Chris Leonard

For example, regarding scripting:

stackoverflow.com/questions/100672...

Lots of other discussions around, but that should get you started.

Collapse
 
buinauskas profile image
Evaldas Buinauskas • Edited

That & after a command literally means to run a command in background (or you can call it async). Quite useful to trigger long running tasks.

Collapse
 
puritanic profile image
Darkø Tasevski

Thanks for clearing that up for me!

 
puritanic profile image
Darkø Tasevski

Well, if you put it that way :D I guess you're right. Nevertheless, I don't think that I will write scripts for other users than me anytime soon.