I just found this message in Spam, so I did not ignore it intentionally. On Sun, Jul 15, 2018 at 11:47 PM Simon McVittie <s...@debian.org> wrote:
> 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 >
