Nice summary. Also pretty much a short list of reasons why I started to write even simple scripts in awk or python when they get too long. Another long topic is quoting variables, $ inside strings and expansion before execution... Opinions may vary of course, but I've found it easier to just write this (or whatever you need) and deal with normal variables and normal lex-and-parse-before-expansion/execution language:
I like that approach, and I usually find myself doing the same thing. Just be sure when writing a Python "executable" that the first line is:
#!/usr/bin/env python
Since python is not a POSIX-specified utility, it might be anywhere on the user's PATH. Using the env trampoline (it is guaranteed to be available at /usr/bin/env) will allow your script to work on any POSIX system that has Python installed and on the PATH.
In a brief search, I wasn't able to find a canonical location of awk defined in POSIX, so it might be necessary to use env for that, too.
POSIX does not define canonical locations of any binaries, not even sh (Ahell & Utilities, sh, Application Usage). Only things that are specified in POSIX by exact path (Base Definitions, 10.1) are /dev/null, /dev/tty, /dev/console and /tmp.
Using /usr/bin/env is common practice, but not standardized in any way. Also, POSIX does not specify the '#!' syntax, and only documents the original mechanism of running shell scripts (execl/vp() passes anything that is not understood by kernel to sh).
Small nitpick with the ".sh" - it's false advertising once it's become a bash script; but don't just go to ".bash", rather just drop it and it's set. And soon, otherwise users write other programs depending on the script's name - with ".sh", then you reimplement in python/perl and bemoan that your alleged shell script is now a wolf in sheep's clothing, then reimplement it in C - and that ".sh" is still stuck there, a strange historical note that now undermines the entire original reason for putting an extension on it at all.
Commands shouldn't have extensions, ever, on Unix or its variants. Unix has magic numbers and interpreter directives, DOS has extensions and the ability to ignore them when looking up commands ... never the twain should meet.
Wasn't it lowercase-linux that ran away with its own default shell? I mean, the whole confusion starts when "/bin/sh" is a simlink to "bash".
And we haven't considered the confusion that Bash, when invoked as "/bin/sh" behaves differently than both the Bourne shell and Bash invoked as "/bin/bash".
Due to the same problem you mention, many Linux shell startup scripts are a mess as well. The /etc/profile actually reads in a /etc/bash.bashrc if $BASH is set on Ubuntu, instead of taking the correct approach of letting Bash handles its own startup. One some system (either Redhat or Ubuntu or CentOS, can't remember which) ends up reading in bash's startup scripts in the wrong order - and the wrong number of times.
Instead of cramming things in /etc/profile (which really should only be about environment variables, where ~/.bashrc should pick most of them up from the parent process), just having ~/.bash_login read ~/.bashrc solves getting all your interactive bash startup commands into one file (assuming the /etc/skel/.* is used during account creation so users don't have to set that up themselves).
This is a good article; it's easy to learn shell scripting without understand bashisms vs POSIX or keeping track of what are external commands and what are shell builtins. This will leave you pulling your hair out later, as the article demonstrates.
1. POSIX /bin/echo does not recognize any options other than "-n", and "-n" is "implementation-defined". [0] So you end up right back at the same problem.
2. I highly recommend using built-ins where possible. Invoking /bin/echo instead of using echo involves copying a string into an argument vector, setting argc, loading /bin/echo, attaching std file descriptors, and forking. All of this to print a string to stdout.
It's much better to explicitly specify the behavior you want by invoking the appropriate interpreter, or to use /bin/sh while being sure to stick to POSIX-compliant functionality (e.g. printf).
POSIX specified way to get results you are expecting is "command -p echo", as POSIX does not guarantee where the utilities are located, on the other hand it guarantees that all utilities that are implemented as shell builtins while they don't need to (eg. cd makes sense only as builtin) must also be present on filesystem.
The author's assessment of debian is incorrect (I can't speak for ubuntu). Debian does not replace link /bin/sh to /bin/dash without being instructed by the user to do so. When dash was installed dpkg queries the user about what to do with /bin/sh. If you are unhappy with how you set your system up:
# dpkg-reconfigure -p low dash
Neat unix trivia article but don't blaspheme Debian...
The most common use is "debconf-show packagename", which displays all items in
the debconf database owned by a given package, and their current values.
Questions that have been asked already are prefixed with an '*'.
I don't doubt that that is the case for you. I am saying when dash was installed dpkg asks if it should install the link and you said to install the link. If you want to change it or see the question again:
My fault. I should have realised that this is on a VPS where the OS is installed from a pre-configured image. I guess the VPS provider configured it to use bash.
No worries. I have been a debian user for years. All the doubters above did not bother to run dpkg-reconfigure like you did. Its a shame that people are going to argue about something but never actually do any research. The worst part is that this thread reinforced incorrect beliefs about debian.
On a related note set the debconf priority to low so that you always know the dpkg decisions that go into the creation of your system. That way you are not ignorant like the doubters above...
