Subject: [alpine-devel] Shell scripts

From: Gemsbokella <[email-masked]>
Date: Wed, 02 Nov 2016 17:24:32 -0400

Hello, I discovered Alpine Linux the other day and I immediately fell in love with it. I also enjoy writing shell scripts (well... you know how it is) and I'd therefore be more than happy to write some.

I found a #TODO in setup-xorg-base.in saying you are in need of a GPU driver detection script, so I have it a shot. I think I've just finished writing it. However, I have some questions:

1) I did not find any code guidelines. Can I just make the scripts however I feel like or should I try to mimic the ones you had written before?
2) Do you have any special requirements (i.e., do not create new files, etc.) or do I have free reign while making scripts?
3) Do you require help at all?
4) Is there any easy way to get feedback?
5) Do I just commit the script or should I discuss it beforehand with someone else?

Thank you for reading this post.

---

From: Jakub Jirutka <[email-masked]>
Date: Thu, 3 Nov 2016 00:19:32 +0100

Hi!

> I immediately fell in love with it

Then you’ve come to the right place! :)

> I also enjoy writing shell scripts and I’d therefore be more than happy to write some.

Great to hear that! I also enjoy writing shell scripts, but others often look at me quite weird when I say that… :) Unfortunately most people really don’t know shell well, so it’s quite rare.

> 1) I did not find any code guidelines. Can I just make the scripts however I feel like or should I try to mimic the ones you had written before?

True, we should write some. Few rules that I’ve just remembered:

* 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).

> 2) Do you have any special requirements (i.e., do not create new files, etc.) or do I have free reign while making scripts?

Hard to say in advance, send your patch and we will see.

> 3) Do you require help at all?

Of course, contributors are always welcome!

> 4) Is there any easy way to get feedback?

Yes, the most straightforward is to open a pull request on GitHub (https://github.com/alpinelinux/) and someone will do a code-review. It’s very convenience for that. Another option is to send your patch to the mailing list.
You can also join IRC channel #alpine-devel.

> 5) Do I just commit the script or should I discuss it beforehand with someone else?

It depends. It’s not strictly required, but usually it’s better to ask before you spent huge amount of time on something that may not be welcome for some reason.

Jakub

> On 2. Nov 2016, at 22:24, Gemsbokella <[email-masked]> wrote:
>