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.
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]).
> 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.
smcv
[1] https://www.debian.org/doc/debian-policy/#scripts
