4 ms·

See https://shellcheck.net https://shellcheck.net to fix your script and follow good guidelines. Top of my head: * /bin/bash -> /usr/bin/env bash * You probab

See https://shellcheck.net https://shellcheck.net to fix your script and follow good guidelines. Top of my head: * /bin/bash -> /usr/bin/env bash * You probably don't need bash anyway, so switch to /bin/sh * errors go to stderr (>&2), not stdout * exits because of errors should return non-zero codes. (e.g.: `exit 1`) * Full caps variables are bad practise (might conflict with real, global env variables) * rather than running everything as root (using sudo), I'd call sudo for the only few commands that actually require root privileges (I found none, so I suppose "security" is the only command that needs root perms).

RossM 8y ago
Thank you for sharing this; I infrequently have to write standalone shell scripts but every time I do I spend a while looking around for best practices and often just end up with some contradicting opinions.
- moviuro 8y ago
  I usually refer to http://mywiki.wooledge.org/BashFAQ http://mywiki.wooledge.org/BashFAQ , which is what anyone on #bash IRC channel would recommend. Good luck!
- m0nty 8y ago
  There's also this: https://news.ycombinator.com/item?id=6866085 https://news.ycombinator.com/item?id=6866085 And the Google 'Shell Style Guide': https://google.github.io/styleguide/shell.xml https://google.github.io/styleguide/shell.xml Just in case you hadn't seen them already.
  - moviuro 8y ago
    Just for the record, the Google guide focuses on Google infrastructure and systems, not portability. Using /bin/bash for instance is not a good idea if you want to port your work to BSD systems.
    - richardwhiuk 8y ago
      Which you probably don't care about.
    - stephenr 8y ago
      Bash isn't even a good choice if you want to support just macOS and Linux, because the versions available are so wildly different.
      - jsjohnst 8y ago
        1) supporting both macOS and Linux in bash is trivial. Just stick to Bash 3 functionality. 2) Bash4 is trivial to install on macOS via home brew, so saying “available” is a misnomer. “Default” would be a bit better, but many Linux distros still in use don’t use Bash4. 3) Bash 3 vs 4 isn’t “wildly” different.
xorcist 8y ago
A lot of people use full caps variables in shell scripts, I wouldn't worry about that. However, I'd like to add: * Indentation is mad. "exit" seems to cause preceding lines to be indented. This is code, treat it as such. * Only split a command in two where it increases readability. Type "rm +.txt +.doc" if that's what you mean, not "rm +.txt ; rm +.doc". (Substitute + for asterisks; don't know how to avoid markdown.) The asterisks already expands to multiple filenames. * When rm:ing files in shell scripts using "-f" is likely a good idea. Interactive aliases or unexpected permissions might trip you up otherwise. * But removing everything in your-certs is probably a surprise for the user. You would expect the script to generate a new certificate, not erase old ones! * Don't do an if-construct every time you mkdir something. Just do "mkdir -p" instead, that makes sure directories exist and creates them if necessary. * The config file needs to be specified with a full path, or at least checked if it exists. If you place it in the same directory as the script, use "dirname $0" to figure out the path. * That config file is so small you might as well store it in the script and cat << EOF it directly through sed to disk. Or even use variable substitution directly. * If you need temporary files for some reason, it's good practice to use mktemp to allocate them which gives you uniqueness and a suitable tmp folder for free. * That awk-construct is perhaps not obvious to everyone. Just do "for fprint in $(... | grep)" instead. Or "security .. | while read" if there are more than a handful. * Not setting umask could potentially render key material readable to other users. Don't do this. * Don't generate a new CA every run. Keep it around in a directory (with proper permissions) and only generate a new if not already present in the trust store. Sometimes you may trip on applications not willing to accept a new certificate with the same serial number as an old one. If this is something you need to take into account, just store used serial numbers in the same directory as your CA keys. It should also be noted that openssl ships with a script does all this, except installing the trusted certificate in the trust store.
LinuxBender 8y ago
I would also add set -u in all scripts. Then set +u when you need something undefined such as a case statement.

RossM 8y ago

Thank you for sharing this; I infrequently have to write standalone shell scripts but every time I do I spend a while looking around for best practices and often just end up with some contradicting opinions.

moviuro 8y ago
I usually refer to http://mywiki.wooledge.org/BashFAQ http://mywiki.wooledge.org/BashFAQ , which is what anyone on #bash IRC channel would recommend. Good luck!
m0nty 8y ago
There's also this: https://news.ycombinator.com/item?id=6866085 https://news.ycombinator.com/item?id=6866085 And the Google 'Shell Style Guide': https://google.github.io/styleguide/shell.xml https://google.github.io/styleguide/shell.xml Just in case you hadn't seen them already.
- moviuro 8y ago
  Just for the record, the Google guide focuses on Google infrastructure and systems, not portability. Using /bin/bash for instance is not a good idea if you want to port your work to BSD systems.
  - richardwhiuk 8y ago
    Which you probably don't care about.
  - stephenr 8y ago
    Bash isn't even a good choice if you want to support just macOS and Linux, because the versions available are so wildly different.
    - jsjohnst 8y ago
      1) supporting both macOS and Linux in bash is trivial. Just stick to Bash 3 functionality. 2) Bash4 is trivial to install on macOS via home brew, so saying “available” is a misnomer. “Default” would be a bit better, but many Linux distros still in use don’t use Bash4. 3) Bash 3 vs 4 isn’t “wildly” different.

xorcist 8y ago

A lot of people use full caps variables in shell scripts, I wouldn't worry about that. However, I'd like to add: * Indentation is mad. "exit" seems to cause preceding lines to be indented. This is code, treat it as such. * Only split a command in two where it increases readability. Type "rm +.txt +.doc" if that's what you mean, not "rm +.txt ; rm +.doc". (Substitute + for asterisks; don't know how to avoid markdown.) The asterisks already expands to multiple filenames. * When rm:ing files in shell scripts using "-f" is likely a good idea. Interactive aliases or unexpected permissions might trip you up otherwise. * But removing everything in your-certs is probably a surprise for the user. You would expect the script to generate a new certificate, not erase old ones! * Don't do an if-construct every time you mkdir something. Just do "mkdir -p" instead, that makes sure directories exist and creates them if necessary. * The config file needs to be specified with a full path, or at least checked if it exists. If you place it in the same directory as the script, use "dirname $0" to figure out the path. * That config file is so small you might as well store it in the script and cat << EOF it directly through sed to disk. Or even use variable substitution directly. * If you need temporary files for some reason, it's good practice to use mktemp to allocate them which gives you uniqueness and a suitable tmp folder for free. * That awk-construct is perhaps not obvious to everyone. Just do "for fprint in $(... | grep)" instead. Or "security .. | while read" if there are more than a handful. * Not setting umask could potentially render key material readable to other users. Don't do this. * Don't generate a new CA every run. Keep it around in a directory (with proper permissions) and only generate a new if not already present in the trust store. Sometimes you may trip on applications not willing to accept a new certificate with the same serial number as an old one. If this is something you need to take into account, just store used serial numbers in the same directory as your CA keys. It should also be noted that openssl ships with a script does all this, except installing the trusted certificate in the trust store.

LinuxBender 8y ago

I would also add set -u in all scripts. Then set +u when you need something undefined such as a case statement.