Re: GoRedo shell specification?

From: Sergey Matveev <stargrave_at_domain.hidden>
Date: Fri, 26 Feb 2021 23:59:18 +0300
Message-ID: <YDlhMZ7LYPYo5S4E_at_domain.hidden>
*** Norman Kabir [2021-02-26 14:15]:
>*> executable .do is run as is, non-executable is run with /bin/sh -e[x]*
>What is the motivation for this behavior? It's different from
>apenwarr's implementation.

Several other implementations (not sure, but I remember that actually
the most I saw) also differs from apenwarr and goredo and only execute
(executable) .do files.

I like approach of executable .do-s because it requires literally
nothing from the redo implementation itself -- the kernel does all the
job: parsing shebangs and executing necessary command line. It is
versatile: you can use binary object files, or shebang-ed scripts of any
language you prefer.

But also I believe that most of .do-s are POSIX shell scripts in
practice. And the tool should be convenient and helpful. It is annoying
to keep "#!/bin/sh" in every single .do file. Moreover it is *very*
convenient to have ability to switch on (set -x) trace flag to see what
happens during the .do's invocation. So redo implementation have to have
some way of turning "-x" flag on. And here is convenient suggestion of
keeping .do files shebangless with explicit "-x" control. And you
differentiate "universal" .do files from shebangless ones with
executable permission bit.

Executable .do-s will work everywhere, but you loose ability to control
"-x" flag if it is POSIX shell. Or you may parse the .do and make the
work kernel already does. Non-executable .do-s are just convenient
single use-case. I see no reason of non-executable shebang-ed .do,
because if it is not POSIX shell script, then you can not safely add
"-x" flag to it and its behaviour does not differ from the executable one.

Also there is some critique of apenwarr's .do parsing (I am agreed with)
at the bottom of that page:

Sergey Matveev (
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Received on 2021-02-26 20:59:18 UTC

This archive was generated by hypermail 2.4.0 : 2021-02-26 21:00:08 UTC