On Wed, 26 Jun 2024, 03:14 Chet Ramey, <chet.ra...@case.edu> wrote:
> On 6/19/24 6:12 PM, konsolebox wrote:
>
> > Alternatively, have BASH_SOURCE always produce real physical paths
> > either by default or through a shopt.
>
> This is the best option. I don't think changing bash to do this by default
> would have negative side-effects.
>
Just to be clear, would this result in $0 and ${BASH_SOURCE[@]:(-1):1}
potentially yielding different values?
(I would certainly hope so, otherwise how would we be able to alter the
behaviour of a script based on the name used to invoke it? And before
anyone tells me what a bad idea that would be, sometimes it's necessary to
mimic historical behaviour such as gzip vs gunzip, and there are definitely
scripts out there that rely on this.)
However I do see a minor downside: looking at BASH_SOURCE to decide whether
a given ancestor in the call chain is actually $0, the naive string
comparison will now fail. This isn't important to most programs, but may be
necessary for, say, a debugging framework.
I have a small pure-Bash library that mimics Perl's "Carp.pm", providing
"carp" , "cluck", "croak", and "confess". One feature I'm in the process of
adding is suppression of specific "modules" from the backtrace displayed
after a message; in this context I equate "module" with "source file".
Since this is new for me, I can just document that users must use
${BASH_SOURCE[@]:(-1):1} rather than $0 when asking my "Carp" module to
exclude its own "main" from backtraces.
But if someone else has already implemented this, then their code will be
subtly broken by this proposed change to Bash.
-Martin
>
