[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed BASH_SOURCE_PATH
From: |
konsolebox |
Subject: |
Re: proposed BASH_SOURCE_PATH |
Date: |
Tue, 6 Aug 2024 15:09:18 +0800 |
On Thu, Jul 25, 2024 at 9:10 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 7/18/24 4:44 PM, konsolebox wrote:
> > On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey <chet.ramey@case.edu> wrote:
> >>
> >> On 7/11/24 3:51 AM, konsolebox wrote:
> >>> On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey <chet.ramey@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
- Re: proposed BASH_SOURCE_PATH,
konsolebox <=