Mail archive

[alpine-devel] Shell scripting guidelines

From: Gemsbokella <>
Date: Sat, 05 Nov 2016 15:06:28 -0400

Hi! I think it's about time we make official shell scripting guidelines. First of all, we need a mainter of such set of rules. The process of accepting new rules should be of course democratic but there needs to be someone (or a group) that compiles those rules. Any volunteers? I guess I could do it if no one else is interested.

In my opinion, it would be ideal to have 3 sets of rules. Style guide, preferences guide which mandates requirements of the actual script (`set -u`, POSIX-sh), and so called "dealing with a specific task" [WIP name] that advises programmers how to deal with a task (e.g., user input)

I hear there's already a few established rules (courtesy of <>)

* Follow POSIX-sh standard, avoid “bashisms”. But we are pragmatic, so if some non-POSIX feature is supported by all commonly used shells (Busybox ash, dash, zsh, bash, …) and it has substantial benefits, then it’s okay to use it (for example `local` and `${var/pattern/replacement}`). Actually, in the case of `local`, you should always prefer it over polluting global namespace. I should also note that Alpine uses Busybox ash as default shell.
* Use `set -e` and if possible also `set -u` (called at the top of the script) in newly created scripts. Unfortunately this is not a common practice in existing scripts (yet) and it already caused a lot trouble…
* Prefer lower_case for names of variables and functions, except global constants and environment variables.
* We don’t usually use curly braces around variables if they are not needed.
* Use tabs for indentation, not spaces (and better to avoid spaces alignment, because it sooner or later ends as a mess).
If you like my "3 set of rules" idea, you end up with this:

* Use tabs for indentation
* Avoid spaces alignment
* No curly braces around variables if they are not needed
* lower_case names of variables and functions, except for global constants and environment variables

* Follow POSIX-sh standard, if non-POSIX is supported by common shells and offers better solution it is OK to use it
* Use `set -e` and if possible also `set -u`
* `local` is preffered over polluting global namespace

===Dealing with specific tasks===

There are a few problems we need to discuss (I'd appreciate your opinions):
* User input
* License
* printf vs echo

Question 1: User input is very hard to get right, especially in shell scripts. How to deal with invalid input? Ask again? Exit?
Opinion 1: I personally ask the user again. Another common practise is just to quit the script which, frankly, is not a very good solution.

Question 2: Prefered license for shell scripts
Opinion 2: GPLv2, GPLv3 or BSD would suit the scripts just fine.

Question 3: printf vs echo
Opinion 3: 99% of the time echo ( I think we should accept this as a rule ASAP.

Find a better name for "dealing with specific tasks"

So, what do you think? Is this even a good idea?

Received on Sat Nov 05 2016 - 15:06:28 GMT