Re: proposed BASH_SOURCE_PATH

On 8/6/24 3:09 AM, konsolebox wrote: 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. You mean for the paths that were added to BASH_SOURCE before setting the

Re: proposed BASH_SOURCE_PATH

On Tue, Aug 6, 2024 at 3:09 PM konsolebox wrote: > > On Thu, Jul 25, 2024 at 9:10 PM Chet Ramey wrote: > > > > On 7/18/24 4:44 PM, konsolebox wrote: > > > On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey wrote: > > >> > > >> On 7/11/24 3:51 AM, konsolebox wrote: > > >>> On Thu, Jul 11, 2024 at 4:08 A

Re: proposed BASH_SOURCE_PATH

On Thu, Jul 25, 2024 at 9:10 PM Chet Ramey wrote: > > On 7/18/24 4:44 PM, konsolebox wrote: > > On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey wrote: > >> > >> On 7/11/24 3:51 AM, konsolebox wrote: > >>> On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey wrote: > and the BASH_SOURCE > absolute pa

Re: proposed BASH_SOURCE_PATH

s : BASH_SOURCE_REAL : BASH_SOURCE_ABSOLUTE On Thu, Jul 25, 2024, 15:10 Chet Ramey wrote: > On 7/18/24 4:44 PM, konsolebox wrote: > > On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey wrote: > >> > >> On 7/11/24 3:51 AM, konsolebox wrote: > >>> On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey > wrote: > >

Re: proposed BASH_SOURCE_PATH

On 7/18/24 4:44 PM, konsolebox wrote: On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey wrote: On 7/11/24 3:51 AM, konsolebox wrote: On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey wrote: and the BASH_SOURCE absolute pathname discussion has been bananas, so that's not going in any time soon. Maybe j

Re: proposed BASH_SOURCE_PATH

On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey wrote: > > On 7/11/24 3:51 AM, konsolebox wrote: > > On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey wrote: > >> and the BASH_SOURCE > >> absolute pathname discussion has been bananas, so that's not going in any > >> time soon. > > > > Maybe just create BASH

Re: proposed BASH_SOURCE_PATH

On 7/11/24 3:51 AM, konsolebox wrote: On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey 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 us

Re: proposed BASH_SOURCE_PATH

On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey 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. https://gist.github.com/konsolebox/d9fb2fadd2b8b13d96d0aa7ebea836d9#fil

Re: proposed BASH_SOURCE_PATH

On 7/7/24 3:34 PM, Greg Wooledge wrote: At this point, I'm just going to wait and see what gets implemented, and then figure out how that affects scripts and interactive shells in the future. I added -p to ./source, but that's it. It's in the devel branch. There's no reason to continue discuss

Re: proposed BASH_SOURCE_PATH

On Mon, Jul 8, 2024 at 11:16 AM Martin D Kealey wrote: > The only things that the shell has going for it is that it's widely deployed > and stable over the long term. > Otherwise it's a terrible language, and any sane programmer should avoid it > entirely: > This has already been happening, and

Re: proposed BASH_SOURCE_PATH

@Greg, @Martin +1, lost sight of the feature, and xing fingers that current semantic/behavior is not destroyed, @Oğuz -1 I'd like to avoid fixing script that run today just because bash was updated or I would advocate distros to keep a frozen bash as macos did.

Re: proposed BASH_SOURCE_PATH

On Mon, Jul 8, 2024, 10:16 Martin D Kealey wrote: > > > On Mon, 8 Jul 2024 at 14:42, Oğuz wrote: > >> On Monday, July 8, 2024, Martin D Kealey wrote: >>> >>> It's not possible to change "${BASH_SOURCE[@]}" without breaking some >>> existing code, >>> >> >> It's worth breaking existing code in t

Re: proposed BASH_SOURCE_PATH

On Mon, 8 Jul 2024 at 14:42, Oğuz wrote: > On Monday, July 8, 2024, Martin D Kealey wrote: >> >> It's not possible to change "${BASH_SOURCE[@]}" without breaking some >> existing code, >> > > It's worth breaking existing code in this case. > The only things that the shell has going for it is th

Re: proposed BASH_SOURCE_PATH

On Monday, July 8, 2024, Martin D Kealey wrote: > > It's not possible to change "${BASH_SOURCE[@]}" without breaking some > existing code, > It's worth breaking existing code in this case. which leaves us with some kind of explicit opt-in such as: > `shopt -s compat52' should suffice to opt out

Re: proposed BASH_SOURCE_PATH

On Mon, 8 Jul 2024, 05:23 alex xmb sw ratchev, wrote: > i dont get the BASH_SOURCE[n] one > the point of prefix $PWD/ infront of relative paths is a static part of > fitting into the first lines of the script , assigning vars > That's not the only use case. Consider where you have a script that

Re: proposed BASH_SOURCE_PATH

On Sun, Jul 07, 2024 at 21:23:15 +0200, alex xmb sw ratchev wrote: > hi .. > i dont get the BASH_SOURCE[n] one > the point of prefix $PWD/ infront of relative paths is a static part of > fitting into the first lines of the script , assigning vars > .. if u cd first then want the old relative path .

Re: proposed BASH_SOURCE_PATH

On Sun, Jul 7, 2024, 21:03 Chet Ramey wrote: > On 7/3/24 5:32 PM, alex xmb sw ratchev wrote: > > 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 ,

Re: proposed BASH_SOURCE_PATH

On 7/3/24 5:32 PM, alex xmb sw ratchev wrote: 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 The objection is that people don't want to

Re: proposed BASH_SOURCE_PATH

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

Re: proposed BASH_SOURCE_PATH

On Thu, Jul 4, 2024 at 2:54 AM Chet Ramey wrote: > 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 on

Re: proposed BASH_SOURCE_PATH

On 7/3/24 2:37 PM, konsolebox wrote: On Mon, Jul 1, 2024 at 10:56 PM Chet Ramey wrote: On 6/26/24 5:59 AM, konsolebox wrote: On Tue, Jun 25, 2024 at 11:14 PM Chet Ramey wrote: On 6/19/24 6:12 PM, konsolebox wrote: Alternatively, have BASH_SOURCE always produce real physical paths either

Re: proposed BASH_SOURCE_PATH

On Mon, Jul 1, 2024 at 10:56 PM Chet Ramey wrote: > > On 6/26/24 5:59 AM, konsolebox wrote: > > On Tue, Jun 25, 2024 at 11:14 PM Chet Ramey wrote: > >> > >> On 6/19/24 6:12 PM, konsolebox wrote: > >> > >>> Alternatively, have BASH_SOURCE always produce real physical paths > >>> either by default

Re: proposed BASH_SOURCE_PATH

On 6/26/24 7:18 PM, Martin D Kealey wrote: But unfortunately in this case, BASH_ARGC[0] is 1 rather than 0,, and the filename provided to "source" (now ${BASH_SOURCE[0]}) is prepended to BASH_ARGV. Because that's the state of this call frame, and that's what the bash debugger -- why these va

Re: proposed BASH_SOURCE_PATH

On 6/26/24 8:17 AM, Martin D Kealey wrote: On Wed, 26 Jun 2024, 03:14 Chet Ramey, > 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

Re: proposed BASH_SOURCE_PATH

On 6/26/24 7:18 PM, Martin D Kealey wrote: I've found some existing code that will break if words in ${BASH_SOURCE[@]} don't match the filepath given to '.' or 'source':   [[ ${BASH_ARGV[0]} = "${BASH_SOURCE[0]}" ]] which is part of a test to determine whether any args were provided after "sou

Re: proposed BASH_SOURCE_PATH

On 6/26/24 5:59 AM, konsolebox wrote: On Tue, Jun 25, 2024 at 11:14 PM Chet Ramey 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

Re: proposed BASH_SOURCE_PATH

I've found some existing code that will break if words in ${BASH_SOURCE[@]} don't match the filepath given to '.' or 'source': [[ ${BASH_ARGV[0]} = "${BASH_SOURCE[0]}" ]] which is part of a test to determine whether any args were provided after "source filename". I use this at the end of my file

Re: proposed BASH_SOURCE_PATH

Le 26/06/2024 à 14:17, Martin D Kealey écrivait : Just to be clear, would this result in $0 and ${BASH_SOURCE[@]:(-1):1} potentially yielding different values? There is no reason it would alter the content of $0 which remains the name of the command involved. The arguments vector with index

Re: proposed BASH_SOURCE_PATH

On Wed, Jun 26, 2024 at 8:57 PM Chet Ramey wrote: > What `lazy alternatives' did you have in mind? I replied to Martin D Kealey about it but looking at the email now it seems like he's referring to something involving BASH_SOURCE_PATH instead of BASH_SOURCE. I misinterpreted. I'm thinking if pe

Re: proposed BASH_SOURCE_PATH

On 6/26/24 5:59 AM, konsolebox wrote: That's great. So will this be implemented soon or will you consider other lazy alternatives first? What `lazy alternatives' did you have in mind? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' -

Re: proposed BASH_SOURCE_PATH

On Wed, 26 Jun 2024, 03:14 Chet Ramey, 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 nega

Re: proposed BASH_SOURCE_PATH

On Tue, Jun 25, 2024 at 11:14 PM Chet Ramey 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 hav

Re: proposed BASH_SOURCE_PATH

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. -- ``The lyf so short, the craft so long

Re: proposed BASH_SOURCE_PATH

On 6/21/24 10:01 AM, Martin D Kealey wrote: I support BASH_SOURCE_PATH as replacing the normal PATH search only for "." and "source". I implemented the -p option to ./source instead. In addition I propose some new '~' expansions which will give concise expression of dirname+realpath without p

Re: proposed BASH_SOURCE_PATH

On Fri, Jun 21, 2024 at 10:01 PM Martin D Kealey wrote: > > I support BASH_SOURCE_PATH as replacing the normal PATH search only for "." > and "source". > > In addition I propose some new '~' expansions which will give concise > expression of dirname+realpath without penalizing code that does not

Re: proposed BASH_SOURCE_PATH

I support BASH_SOURCE_PATH as replacing the normal PATH search only for "." and "source". In addition I propose some new '~' expansions which will give concise expression of dirname+realpath without penalizing code that does not need it. The primary intention is to allow the "standard preamble" t

Re: proposed BASH_SOURCE_PATH

bash xmb.mepath declare -- mef="/data/data/com.termux/files/home/xmb.mepath" declare -- med="/data/data/com.termux/files/home" On Wed, Jun 19, 2024, 10:05 PM Will Allan wrote: > > Not sure how common but this is what makes sense. Or name sourceables > > foo.sh, bar.sh and executables foo, bar so

Re: proposed BASH_SOURCE_PATH

On Thursday, June 20, 2024, Léa Gris wrote: > > Would it be a valid option, then to make BASH_SOURCE contain the real path > in all circumstances? > Sounds good to me. -- Oğuz

Re: proposed BASH_SOURCE_PATH

Le 20/06/2024 à 05:25, Oğuz écrivait : What I'm saying there is name it main and execute like `./main'. I'm not against having a variable that's automatically populated with the parent directory of the source script, I just don't need it and it wasn't what we were discussing. Would it be a val

Re: proposed BASH_SOURCE_PATH

On Wednesday, June 19, 2024, Will Allan wrote: > I think this is exactly why this feature is necessary. Unless I am > misunderstanding, simply prepending `${BASH_SOURCE%/*}' to a sourced path > will not work in all cases. For example, when executing the main script > directly inside the script di

Re: proposed BASH_SOURCE_PATH

Thanks for clarifying! I wondered if I was missing something, but kept seeing `${BASH_SOURCE[0]/%/*}` suggested in the thread, which I pointed out is flawed. I guess what I want is a "BASH_SOURCE_DIR" variable or something like it, mainly to avoid the boilerplate, variable, and/or command substi

Re: proposed BASH_SOURCE_PATH

On Thu, Jun 20, 2024 at 4:05 AM Will Allan wrote: > But, I still don’t like it. I have to start off each script with a slow > command substitution (subshell) which introduces a variable that I don’t > really want, but it’s too slow to do this repeatedly: I agree. > source -- "${BASH_SOURCE_PAT

Re: proposed BASH_SOURCE_PATH

On Thu, Jun 20, 2024 at 4:47 AM Léa Gris wrote: > realSource=$(realpath -- "${BASH_SOURCE[0]}") && > realScriptDir=${realSource%/*} `realScriptDir=$(realpath -m "${BASH_SOURCE}/..") || exit` is simpler if you don't care about versions of realpath not supporting `-m`. It is mostly convenient if y

Re: proposed BASH_SOURCE_PATH

Yes, that's precisely my point. It suddenly becomes more complex and bug prone than at first glance. To do it without a subshell, I need something like this boilerplate at the top of each of my main scripts: if [[ "${BASH_SOURCE[0]}" == */* ]]; then   SCRIPT_DIR="${BASH_SOURCE[0]%/*}" else   SCR

Re: proposed BASH_SOURCE_PATH

2024年6月20日(木) 5:47 Léa Gris : > Look like you did not find a proper answer there. Here is one simple > that involve no sub-shell at all and does exactly what your sub-shell > version does. > > declare -r SCRIPT_DIR=${BASH_SOURCE[0]%/*} This doesn't work as explained by Will. BASH_SOURCE doesn't co

Re: proposed BASH_SOURCE_PATH

Le 19/06/2024 à 22:04, Will Allan écrivait : Since I find the accepted answer to be overly complex for my needs, I usually just do this: declare -r SCRIPT_DIR="$(dirname -- "${BASH_SOURCE[0]}")" source -- "${SCRIPT_DIR}/../lib/foo.sh" source -- "${SCRIPT_DIR}/../lib/bar.sh" ... But, I still don

Re: proposed BASH_SOURCE_PATH

> Not sure how common but this is what makes sense. Or name sourceables > foo.sh, bar.sh and executables foo, bar so they don't clash and source with > `${BASH_SOURCE%/*}' prepended to PATH and it'll work fine. >  > This feature request sounded promising at first, it feels like > bike-shedding now.

Re: proposed BASH_SOURCE_PATH

On Sat, May 18, 2024 at 9:18 AM Martin D Kealey wrote: > On Thu, 16 May 2024 at 22:50, konsolebox wrote: >> >> On Thu, May 16, 2024 at 4:59 PM Martin D Kealey >> wrote: >> > As I understood your counter-proposal, it would result in this: >> > * ./a and ./b/c/d would be treated as relative to $P

Re: proposed BASH_SOURCE_PATH

On 5/16/24 8:37 AM, Oğuz wrote: This feature request sounded promising at first, it feels like bike-shedding now. Yes, nothing's ever easy. We are quickly approaching diminishing returns. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'

Re: proposed BASH_SOURCE_PATH

On 5/16/24 7:02 AM, Martin D Keale (1) it's barely tolerable to add more action-at-a-distance by introducing a new variable; but adding *invisible* action at a distance is a language design antipattern. Having `-i` on the `source` command documents that new behaviour is expected. What `invis

Re: proposed BASH_SOURCE_PATH

bad gmail app buggs sorry , missed ending } [[ $BASH_SOURCE == /* ]] && medir=${BASH_SOURCE%/*} || { [[ $BASH_SOURCE != */* ]] && medir=$PWD || medir=$PWD/${BASH_SOURCE%/*} } On Thu, May 16, 2024, 15:48 alex xmb sw ratchev wrote: > maybe this one > > [[ $BASH_SOURCE == /* ]] && > medir=${

Re: proposed BASH_SOURCE_PATH

maybe this one [[ $BASH_SOURCE == /* ]] && medir=${BASH_SOURCE%/*} || { [[ $BASH_SOURCE != */* ]] && medir=$PWD || medir=$PWD/${BASH_SOURCE%/*} } On Thu, May 16, 2024, 15:45 alex xmb sw ratchev wrote: > > > On Thu, May 16, 2024, 15:43 alex xmb sw ratchev wrote: > >> >> >> On Thu, May 16, 20

Re: proposed BASH_SOURCE_PATH

On Thu, May 16, 2024, 15:43 alex xmb sw ratchev wrote: > > > On Thu, May 16, 2024, 14:37 Oğuz wrote: > >> On Wednesday, May 15, 2024, Chet Ramey wrote: >> >> > is it more common to have >> > something like the script in somewhere/bin, files to be sourced in >> > somewhere/lib, and so on? >> >>

Re: proposed BASH_SOURCE_PATH

On Thu, May 16, 2024, 14:37 Oğuz wrote: > On Wednesday, May 15, 2024, Chet Ramey wrote: > > > is it more common to have > > something like the script in somewhere/bin, files to be sourced in > > somewhere/lib, and so on? > > > Not sure how common but this is what makes sense. Or name sourceables

Re: proposed BASH_SOURCE_PATH

On Wednesday, May 15, 2024, Chet Ramey wrote: > is it more common to have > something like the script in somewhere/bin, files to be sourced in > somewhere/lib, and so on? Not sure how common but this is what makes sense. Or name sourceables foo.sh, bar.sh and executables foo, bar so they don't

Re: proposed BASH_SOURCE_PATH

On Thu, 16 May 2024 at 03:03, Chet Ramey wrote: > On 5/14/24 2:08 AM, Martin D Kealey wrote: > > I wholeheartedly support the introduction of BASH_SOURCE_PATH, but I > would > > like to suggest three tweaks to its semantics. > > > > A common pattern is to unpack a script with its associated libra

Re: proposed BASH_SOURCE_PATH

On Thu, May 16, 2024 at 4:59 PM Martin D Kealey wrote: > On Wed, 15 May 2024 at 16:33, konsolebox wrote: >> >> On Wed, May 15, 2024 at 7:16 AM Martin D Kealey >> wrote: >> >> > I'm concerned that doing both would introduce an entirely new dichotomy >> > for programmers to have to remember, so

Re: proposed BASH_SOURCE_PATH

On Thu, 16 May 2024 at 02:48, Koichi Murase wrote: > 2024年5月14日(火) 15:09 Martin D Kealey : > > 1. I therefore propose that where a relative path appears in > > BASH_SOURCE_PATH, it should be taken as relative to the directory > > containing $0 (after resolving symlinks), rather than relative to $

Re: proposed BASH_SOURCE_PATH

On Thu, May 16, 2024 at 10:51:01AM +0700, Robert Elz wrote: > Personally, I don't think there is anything common here at all, most > scripts don't fetch bits from other places, everything simply goes in > the script, and the need for the '.' command at run time is avoided. > > In general, I suspec

Re: proposed BASH_SOURCE_PATH

Date:Wed, 15 May 2024 11:03:12 -0400 From:Chet Ramey Message-ID: | That assumes a flat directory structure for the script and its associated | files, correct? How common is that really? Or is it more common to have | something like the script in somewhere/bin,

Re: proposed BASH_SOURCE_PATH

On 5/14/24 4:10 AM, konsolebox wrote: On Tue, May 14, 2024 at 2:09 PM Martin D Kealey wrote: 1. I therefore propose that where a relative path appears in BASH_SOURCE_PATH, it should be taken as relative to the directory containing $0 (after resolving symlinks), rather than relative to $PWD. T

Re: proposed BASH_SOURCE_PATH

On 5/14/24 2:08 AM, Martin D Kealey wrote: I wholeheartedly support the introduction of BASH_SOURCE_PATH, but I would like to suggest three tweaks to its semantics. A common pattern is to unpack a script with its associated library & config files into a new directory, which then leaves a problem

Re: proposed BASH_SOURCE_PATH

On 5/15/24 10:46 AM, Koichi Murase wrote: Yeah, as far as we resolve the paths by ourselves and specify the absolute path to the `source' builtin, it would reliably work. Even BASH_SOURCE_PATH is unnecessary. kre made the same point earlier. -- ``The lyf so short, the craft so long to lerne.'

Re: proposed BASH_SOURCE_PATH

2024年5月14日(火) 15:09 Martin D Kealey : > A common pattern is to unpack a script with its associated library & config > files into a new directory, which then leaves a problem locating the > library files whose paths are only known relative to $0 (or > ${BASH_SOURCE[0]}). > > 1. I therefore propose t

Re: proposed BASH_SOURCE_PATH

2024年5月15日(水) 13:13 Peng Yu : > On Tue, May 14, 2024 at 3:35 AM Koichi Murase wrote: > > I totally agree that we should have a way to specify the files in > > subdirectories by the path relative to the current script file. > > I currently use something like this to source script files relatively.

Re: proposed BASH_SOURCE_PATH

On 5/14/24 2:08 AM, Martin D Kealey wrote: 2. Search BASH_SOURCE_PATH when any relative path is given, not just a path that lacks a '/', so that libraries can be organized into subdirectories. This is already the behavior when not in posix mode. -- ``The lyf so short, the craft so long to ler

Re: proposed BASH_SOURCE_PATH

On Wed, May 15, 2024 at 7:16 AM Martin D Kealey wrote: > I'm concerned that doing both would introduce an entirely new dichotomy for > programmers to have to remember, so perhaps "skip path searching" should be > controlled by a separate switch, perhaps '-s'? No. `source` already searches PAT

Re: proposed BASH_SOURCE_PATH

On Tue, May 14, 2024 at 3:35 AM Koichi Murase wrote: > > 2024年5月14日(火) 15:09 Martin D Kealey : > > 1. I therefore propose that where a relative path appears in > > BASH_SOURCE_PATH, it should be taken as relative to the directory > > containing $0 (after resolving symlinks), rather than relative t

Re: proposed BASH_SOURCE_PATH

On Tue, 14 May 2024 at 20:10, konsolebox wrote: > On Tue, May 14, 2024 at 2:09 PM Martin D Kealey > wrote: > > 2. Search BASH_SOURCE_PATH when any relative path is given, not just a > path > > that lacks a '/', so that libraries can be organized into subdirectories. > > I disagree with this. Pa

Re: proposed BASH_SOURCE_PATH

This needs to resolve symbolic links otherwise path will be that of the symbolic link rather than that of the actual script file: There are already ways to safely allow sourcing libraries relative to a bash script installation without adding features to Bash: # Create tests and library fold

Re: proposed BASH_SOURCE_PATH

Le 14/05/2024 à 08:08, Martin D Kealey écrivait : I wholeheartedly support the introduction of BASH_SOURCE_PATH, but I would like to suggest three tweaks to its semantics. A common pattern is to unpack a script with its associated library & config files into a new directory, which then leaves a

Re: proposed BASH_SOURCE_PATH

2024年5月14日(火) 15:09 Martin D Kealey : > 1. I therefore propose that where a relative path appears in > BASH_SOURCE_PATH, it should be taken as relative to the directory > containing $0 (after resolving symlinks), rather than relative to $PWD. > > As an interim step until that's implemented, please

Re: proposed BASH_SOURCE_PATH

On Tue, May 14, 2024 at 2:09 PM Martin D Kealey wrote: > 1. I therefore propose that where a relative path appears in > BASH_SOURCE_PATH, it should be taken as relative to the directory > containing $0 (after resolving symlinks), rather than relative to $PWD. This implies only the directory where

Re: proposed BASH_SOURCE_PATH

Completely agree with your suggestions. I've proposed suggestion 3 as well in previous emails but consensus was not reached. -- Matheus