I just found this message in Spam, so I did not ignore it intentionally.
On Sun, 15 Jul 2018 at 12:07:30 +0200, Dashamir Hoxha wrote:
> Either you did not look close enough to the code, or you are not
> an expert on bash scripting (bash is a bit cryptic and difficult
> to understand even for experts).
You are right to say that shell scripting (for bash or for Bourne shells
in general) is cryptic and difficult to understand. I've found that many
of the people who understand shell well enough to write correct shell
scripts prefer to avoid writing non-trivial shell scripts, because they
know they will be more productive in a language with fewer sharp edges.
I feel more productive with Bash scripts, maybe because I have
used them for a long time, for non-trivial things.
In my experience, writing a robust shell script requires a lot of
defensive programming (this is not just my personal opinion, Debian
Policy also touches on this [1]).
I always do defensive programming, not always with bash scripting.
> Instead of basing your judgment on general opinions, why don't you
> try to find any particular situation that will break the script in some
> interesting way ;) This is called proof by counter-example.
> If you cannot do this, and if nobody else can do this, then you cannot
> claim that it is not safe to use this script.
You can use proof by counter-example to demonstrate that a particular
shell script is not correct: if your assertion is "this shell script
behaves as documented", finding an input that will make the script
behave not-as-documented disproves that assertion. The converse is
not true. If nobody finds an input that breaks the shell script, that
does not mean that no such input exists: it could equally well mean
that nobody has looked for long enough yet, for instance because they
consider auditing a shell script that doesn't start with set -e [1]
to be an inefficient use of their time.
While `set -e` could be the right thing for trivial administration scripts
(like installation, or running a bunch of commands, etc.), it would be
the wrong thing for a non-trivial application, like 'pw', because it can
leave the application in an inconsistent state. It is a poor substitution
for defensive programming.
Whoever stops auditing this Bash application because it does not
start with `set -e`, does not have the right skills and experience for
reviewing/auditing it.
smcv
[1] https://www.debian.org/doc/debian-policy/#scripts