is this all about adding full path ? to sourcr / . ? for this may add one varname , like BASH_SOURCE_FULL
it seems to me , using BASH_SOURCE , if it doesnt start with / , prefix $PWD , .. else its already i say about nee var cause it'd be a derivate of , like , BASH_SOURCE warm greets .. On Wed, Jul 3, 2024, 20:54 Chet Ramey <chet.ra...@case.edu> wrote: > On 7/3/24 2:37 PM, konsolebox wrote: > > On Mon, Jul 1, 2024 at 10:56 PM Chet Ramey <chet.ra...@case.edu> wrote: > >> > >> On 6/26/24 5:59 AM, konsolebox wrote: > >>> On Tue, Jun 25, 2024 at 11:14 PM 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. > >>> > >>> That's great. So will this be implemented soon or will you consider > >>> other lazy alternatives first? > >>> > >>> I already made a patch for it here: > >>> > https://gist.github.com/konsolebox/a908cf13e511abdf05daec89a9cbdd8d#file-bash-source-real-patch > >> > >> Should your patch make sure that paths supplied to source/. push the > full > >> pathname into BASH_SOURCE? It only handles the name of a shell script > and > >> leaves the pathname associated with a shell function alone. > > > > Sorry it took me a while to reply. Should this be enough? > > So your answer is "yes." Is there anything to be gained by leaving the > pathname to source/. unchanged and just storing the full pathname of the > script file argument? > > I'm looking for input from people who write shell frameworks here. The ones > who were vocal about BASH_SOURCE_PATH, since these concepts seem related. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/ > >
