On Thu, Jul 25, 2024 at 9:10 PM Chet Ramey <chet.ra...@case.edu> wrote:
>
> On 7/18/24 4:44 PM, konsolebox wrote:
> > On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey <chet.ra...@case.edu> wrote:
> >>
> >> On 7/11/24 3:51 AM, konsolebox wrote:
> >>> On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey <chet.ra...@case.edu> wrote:
> >>>> and the BASH_SOURCE
> >>>> absolute pathname discussion has been bananas, so that's not going in any
> >>>> time soon.
> >>>
> >>> Maybe just create BASH_SOURCE_REAL instead to avoid the gripes.
> >>
> >> I don't think so. It's not very useful to have two variables that are so
> >> similar -- it's needless overhead.
> >
> > So I guess it's really now just about BASH_SOURCE.  What's the final
> > decision on this?  I don't think waiting for more input would make a
> > difference.
>
> The best path forward is to enable the behavior with a new shell option,
> initially disabled.

I just saw the new changes and tested it.  It's not useful because
BASH_SOURCE still expands to the relative form after `shopt -s
bash_source_fullpath` is executed in the main script. This is why I
was saying context directories would have to be stored and paths
already stored in BASH_SOURCE would have to be converted to real path
versions the moment the option is enabled; reason why I don't like it
being made optional.  BASH_SOURCE_REAL is still the most sensible
choice.

If this is already final can the option at least be allowed to be
enabled by default at compile time?

https://gist.github.com/konsolebox/9c500cc693c5e22859dc79b2750068a8#file-add-enable-bash-source-fullpath-default-configure-option-patch


-- 
konsolebox

Reply via email to