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.
Thanks.
Marc.
