On Tue, 2 Feb 2021, Marc Aurèle La France wrote:
On Tue, 2 Feb 2021, Chet Ramey wrote:
On Mon, 1 Feb 2021, Marc Aurèle La France wrote:
Currently, only the script's arguments are passed as positional
parameters. For compatibility reasons, $0 cannot be used to also pass the
script's filename, so I'm creating a new BASH_SCRIPT variable instead.
I'm interested in use cases for this feature.
Well, I'll start with the optics, a.k.a. completeness/consistency argument.
It makes little sense to pass the script's arguments, but not its name.
Using $0 for this would have been even more consistent, but that's crying
over spilt milk.
I'm currently using this to greatly reduce code duplication in a framework
that will eventually allow me to...
- Rebuild my system from source, complete with local changes, but without
the distribution fluff I still have left;
- Keep it up date; and
- When the time comes, move it to different hardware.
... all with much less pain than is currently necessary.
To reduce duplication and maintenance effort, I want everything centralised,
instead of the current messy patchwork, including, but not restricted to, my
interactive use of bash. Currently, I set BASH_ENV system-wide which means
all scripts that start with "#! /bin/bash" (but not "#! /bin/sh") inherit
those settings. However, not all scripts need all settings, so to keep
things clean, I'm using $BASH_SCRIPT to classify/differentiate them.
Yes, I could have all such scripts source a file when they start. But isn't
that just another startup file? And duplication. Or pass something through
$1; again duplication. BASH_SCRIPT is a more elegant solution and doesn't
require any intervention from the named script.
If I end up carrying this as a local change, that's fine too. It wouldn't be
the first time.
Anything more on this?
Thanks.
Marc.
