Re: proposed BASH_SOURCE_PATH

2024-07-25 Thread Chet Ramey

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 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.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: proposed BASH_SOURCE_PATH

2024-07-18 Thread konsolebox
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_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.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-07-18 Thread Chet Ramey

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 useful to have two variables that are so
similar -- it's needless overhead.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: proposed BASH_SOURCE_PATH

2024-07-11 Thread konsolebox
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#file-bash-source-real-array-var-patch

This however introduces heavier changes.

I can already see people saying maybe keep this optional.  I don't
like it because you have to store the context directories to be able
to consistently generate the values the moment the option is enabled.

The lazy method I mentioned earlier as well will probably introduce
more code than this for the same reason.  It was only nice in theory.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-07-10 Thread Chet Ramey

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 discussing BASH_SOURCE_PATH, and the BASH_SOURCE
absolute pathname discussion has been bananas, so that's not going in any
time soon.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/




Re: proposed BASH_SOURCE_PATH

2024-07-08 Thread Oğuz
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 Bash is >this< close to become an 
> irrelevant historical footnote.
> If you modify Bash in ways that are not backwards compatible, you're then 
> writing in a new language that no new project is likely to adopt.

These are just your opinions.

> That's what "worth breaking existing code" costs in reality: other people's 
> stuff breaks when they've had zero advance notice, because they aren't the 
> people deciding to upgrade Bash.

This I agree with, but personally I don't think the change we discuss
here is that big.

> PPS: In my opinion, the only hope for Bash to continue to exist in the long 
> term is for it to either:
> (a) absolutely guarantee stability, forsaking all new features; or
> (b) adopt a full suite of features that make it into a "normal" programming 
> language, including: support for modules written for different versions of 
> Bash to safely cohabitate in a single script; lexical scoping with 
> namespaces; being able to store references in variables, including some kinds 
> of handles for filedescriptors, functions, processes, and process groups; 
> some mechanism to perform rewriting during parsing (going well beyond what 
> aliases can do) so that new features can be proposed and implemented in shell 
> before being implemented in the C core. And all of that while not breaking 
> code that doesn't ask for these new features.

You're wasting your breath.



Re: proposed BASH_SOURCE_PATH

2024-07-08 Thread Phi Debian
@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

2024-07-08 Thread alex xmb sw ratchev
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 this case.
>>
>
> 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:
>
>- its syntax resembles no other language, with fun quirks such as
>intentionally mismatched brackets;
>- its lexical tokenization depend on at least 5 different quoting
>styles;
>- text may or may not be evaluated as a numeric expression, based on
>flags set elsewhere with dynamic duration;
>- text may or may not be split into "words" based on delimiters set
>elsewhere with dynamic duration;
>- text may or may not be globbed into matching filenames, yet again
>depending on a dynamic switch;
>- lifetimes for different kinds of entities are controlled by 3
>different overlapping scoping rules;
>- processes are classified and grouped in arcane ways, leading to the
>current complaints about the lifetime of output command substitutions.
>
> If you take away stability then existing code breaks. When that happens
> enough times, people get fed up and either rewrite the code in another
> language, or completely replace it with a different project. When that
> happens enough, there's no point including Bash in the base set for a
> distro, so it's no longer universally available.
>
> This has already been happening, and Bash is >this< close to become an
> irrelevant historical footnote.
>
> If you modify Bash in ways that are not backwards compatible, you're then
> writing in a new language that no new project is likely to adopt.
>
> which leaves us with some kind of explicit opt-in such as:
>>>
>>
>> `shopt -s compat52' should suffice to opt out of the new default. No
>> point in making it more complicated than that.
>>
>
> That is how we got into the current mess: by assuming that "someone" will
> go around and adjust all the already-deployed scripts, by adding a
> "compatNN" option that did not exist when the script was written.
>
> For example, I have a Ubiquiti ER-X router, as do several of my friends
> and family.
> This device has Bash supplied by the vendor. If the vendor ever pushes a
> future version of Bash with breaking updates, even though they will have
> fixed *their* scripts, my internet connection will die before I find out
> that I need to patch the scripts I've installed in it. And then I have to
> go track down the other people who've installed copies of my scripts, and
> get them to update them (which will be difficult if it has broken their
> internet).
>
> That's what "worth breaking existing code" costs in reality: other
> people's stuff breaks when they've had zero advance notice, because they
> aren't the people deciding to upgrade Bash.
>
> -Martin
>
> PS: this situation would be somewhat ameliorated if it were possible to
> use shopt -s compat$CURRENT_BASH_VERSION, so that it won't need modifying
> to be compatible with a future release of Bash. Having to wait until the
> next version of Bash is released before it can be patched to say what
> version it needs is cruel.
>

good idea i had too , compat current bash ver , to be

PPS: In my opinion, the only hope for Bash to continue to exist in the long
> term is for it to either:
> (a) absolutely guarantee stability, forsaking *all* new features; or
> (b) adopt a full suite of features that make it into a "normal"
> programming language, including: support for modules written for different
> versions of Bash to safely cohabitate in a single script; lexical scoping
> with namespaces; being able to store references in variables, including
> some kinds of handles for filedescriptors, functions, processes, and
> process groups; some mechanism to perform rewriting during parsing (going
> well beyond what aliases can do) so that new features can be proposed and
> implemented in shell before being implemented in the C core. And all of
> that while not breaking code that doesn't ask for these new features.
>


Re: proposed BASH_SOURCE_PATH

2024-07-08 Thread Martin D Kealey
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 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:

   - its syntax resembles no other language, with fun quirks such as
   intentionally mismatched brackets;
   - its lexical tokenization depend on at least 5 different quoting styles;
   - text may or may not be evaluated as a numeric expression, based on
   flags set elsewhere with dynamic duration;
   - text may or may not be split into "words" based on delimiters set
   elsewhere with dynamic duration;
   - text may or may not be globbed into matching filenames, yet again
   depending on a dynamic switch;
   - lifetimes for different kinds of entities are controlled by 3
   different overlapping scoping rules;
   - processes are classified and grouped in arcane ways, leading to the
   current complaints about the lifetime of output command substitutions.

If you take away stability then existing code breaks. When that happens
enough times, people get fed up and either rewrite the code in another
language, or completely replace it with a different project. When that
happens enough, there's no point including Bash in the base set for a
distro, so it's no longer universally available.

This has already been happening, and Bash is >this< close to become an
irrelevant historical footnote.

If you modify Bash in ways that are not backwards compatible, you're then
writing in a new language that no new project is likely to adopt.

which leaves us with some kind of explicit opt-in such as:
>>
>
> `shopt -s compat52' should suffice to opt out of the new default. No point
> in making it more complicated than that.
>

That is how we got into the current mess: by assuming that "someone" will
go around and adjust all the already-deployed scripts, by adding a
"compatNN" option that did not exist when the script was written.

For example, I have a Ubiquiti ER-X router, as do several of my friends and
family.
This device has Bash supplied by the vendor. If the vendor ever pushes a
future version of Bash with breaking updates, even though they will have
fixed *their* scripts, my internet connection will die before I find out
that I need to patch the scripts I've installed in it. And then I have to
go track down the other people who've installed copies of my scripts, and
get them to update them (which will be difficult if it has broken their
internet).

That's what "worth breaking existing code" costs in reality: other people's
stuff breaks when they've had zero advance notice, because they aren't the
people deciding to upgrade Bash.

-Martin

PS: this situation would be somewhat ameliorated if it were possible to use
shopt -s compat$CURRENT_BASH_VERSION, so that it won't need modifying to be
compatible with a future release of Bash. Having to wait until the next
version of Bash is released before it can be patched to say what version it
needs is cruel.

PPS: In my opinion, the only hope for Bash to continue to exist in the long
term is for it to either:
(a) absolutely guarantee stability, forsaking *all* new features; or
(b) adopt a full suite of features that make it into a "normal" programming
language, including: support for modules written for different versions of
Bash to safely cohabitate in a single script; lexical scoping with
namespaces; being able to store references in variables, including some
kinds of handles for filedescriptors, functions, processes, and process
groups; some mechanism to perform rewriting during parsing (going well
beyond what aliases can do) so that new features can be proposed and
implemented in shell before being implemented in the C core. And all of
that while not breaking code that doesn't ask for these new features.


Re: proposed BASH_SOURCE_PATH

2024-07-07 Thread Oğuz
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 of the new default. No point
in making it more complicated than that.


-- 
Oğuz


Re: proposed BASH_SOURCE_PATH

2024-07-07 Thread Martin D Kealey
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 uses two independently written
libraries, each comprising a main and number of ancillary files. Each
library is installed in its own directory, but that directory isn't encoded
into the library.

The standard advice would be to add both directories to PATH (or some
stand-in such as BASH_SOURCE_PATH), however remember, these are
independently written libraries, and the same filename could be used for
files in both libraries, or the "main" script.

By far the most straightforward way to avoid this problem is to source
files using paths relative to (the directory containing) the file
containing the "." or "source" statement itself. But there is no fully
general, portable, and reliable ways to do this, since:
* "${BASH_SOURCE[0]}" might be a relative path based on somewhere in PATH
rather than $PWD, or relative to a different $PWD that's been outdated by cd
;
* "${BASH_SOURCE[0]}" might be a symbolic link into a different directory;
* The directory containing any given file might be unreachable from the
root directory (because of filesystem permissions, process restrictions
(SELinux contexts and equivalents on other OSes), version shadowing, mount
shadowing, soft unmounting, mount namespaces, and probably numerous other
reasons I haven't thought of).

While some of these are intractable, Bash itself at least has a better
chance of getting it right than having to embed screeds of boilerplate code
in every "portable" script. (The more portable/reliable the boilerplate
solution is, the larger and more complex it is, and if it involves
realpath, the slower it gets.)

It's not possible to change "${BASH_SOURCE[@]}" without breaking some
existing code, which leaves us with some kind of explicit opt-in such as:
# 1. mark the source command itself
source -r file_in_same_dir.bash

# 2. Change the default behaviour via shopt/-O
#!/bin/bash -Orelsource
source file_in_same_dir.bash

# 3. set all the forward compat options by controlling argv[0]
#!/bin/bash7
source file_in_same_dir.bash

Or else we could use a new variable such as "${BASH_SOURCE_DIR[@]}" to hold
the normalized directories (and they're slightly less work than normalizing
the whole path and then discarding the last component).

Whatever solution is chosen, I would like it to be easier for a script
author to do the right thing than to do the wrong thing. And all the better
if it could quietly fix the myriad scripts out there that assume [[ ${0%/*}
-ef . ]].

-Martin


Re: proposed BASH_SOURCE_PATH

2024-07-07 Thread Greg Wooledge
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 .. no go .. it must be
> done at early codes

By now, we've had many conflicting ideas proposed by different people,
each trying to solve a different problem.  I've long since lost track of
what all of the proposals and concepts were.

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.



Re: proposed BASH_SOURCE_PATH

2024-07-07 Thread alex xmb sw ratchev
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 , .. else its already
>
> The objection is that people don't want to have to do that -- what if you
> change directories after a relative path is added to BASH_SOURCE[n]?
>

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 .. no go .. it must be
done at early codes

one argument is , preserving one to one strings as user passes including
relative paths like spawn script name

.. while also the need for absolute path is not less inportant
i see another var added . BASH_SOURCE_ABSOLUTE , or _REAL , or so , which
bash will fill the path
.. a question is still what to do with symlinks , maybe additional code is
needed

thanks .. greets ..

-- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
>


Re: proposed BASH_SOURCE_PATH

2024-07-07 Thread Chet Ramey

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 have to do that -- what if you
change directories after a relative path is added to BASH_SOURCE[n]?

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: proposed BASH_SOURCE_PATH

2024-07-03 Thread alex xmb sw ratchev
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  wrote:

> 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 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, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
>


Re: proposed BASH_SOURCE_PATH

2024-07-03 Thread konsolebox
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 ones
> who were vocal about BASH_SOURCE_PATH, since these concepts seem related.

Perhaps vanilla scripts, libraries and frameworks can survive with
just the main file resolving to the real path.  The coder just has to
make sure all paths specified to '.' or source are full paths.  But I
think it's better to be consistent.  It comes with fewer surprises and
usage rules.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-07-03 Thread Chet Ramey

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 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, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: proposed BASH_SOURCE_PATH

2024-07-03 Thread konsolebox
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 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?

https://gist.github.com/konsolebox/a908cf13e511abdf05daec89a9cbdd8d#file-bash-source-real-patch

(Same URI but updated; old version in revisions)

There seem to be three places where "bash_source_a" is updated
(evalfile.c, execute_cmd.c, and shell.c), but only the ones in
evalfile.c and shell.c seem to need updating.  The one in
execute_cmd.c copies the source's path from the function's definition
but when the functions are defined, the source's path is also just
copied from bash_source_a as shown in make_function_def's code:

  temp->source_file = 0;
#if defined (ARRAY_VARS)
  GET_ARRAY_FROM_VAR ("BASH_SOURCE", bash_source_v, bash_source_a);
  if (bash_source_a && array_num_elements (bash_source_a) > 0)
temp->source_file = array_reference (bash_source_a, 0);
#endif

I tested it with the following files:

a.sh

declare -p BASH_SOURCE

. ./x/b.sh

a() {
declare -p BASH_SOURCE
}

a


x/b.sh

declare -p BASH_SOURCE


Running ../bash ./a.sh shows the following with similar paths replaced
with '/path/to/bash':


declare -a BASH_SOURCE=([0]="/path/to/bash/t/a.sh")
declare -a BASH_SOURCE=([0]="/path/to/bash/t/x/b.sh" [1]="/path/to/bash/t/a.sh")
declare -a BASH_SOURCE=([0]="/path/to/bash/t/a.sh" [1]="/path/to/bash/t/a.sh")



-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-07-03 Thread Chet Ramey

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 variables exist -- needs.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: proposed BASH_SOURCE_PATH

2024-07-03 Thread Chet Ramey

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 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?


Yes.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: proposed BASH_SOURCE_PATH

2024-07-03 Thread Chet Ramey

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 
"source filename".


konsolebox's proposed change doesn't affect this, only the path given to
bash as a script argument. I asked why he didn't change the other
assignments to BASH_SOURCE, but he hasn't replied yet.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: proposed BASH_SOURCE_PATH

2024-07-01 Thread Chet Ramey

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 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.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: proposed BASH_SOURCE_PATH

2024-06-26 Thread Martin D Kealey
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 called «autoload.bash», which after
defining a function called «autoload», has:

if [[ -n "$*" ]] && ! {
> (( BASH_ARGC[0] == 1 )) && [[ ${BASH_ARGV[0]} = "${BASH_SOURCE[0]}" ]]
> ||
> (( BASH_ARGC[0] == 0 && ${#BASH_ARGC[@]} > 0 )) # in case this gets
> fixed sometime
>}
> then
> autoload -- "$@"
> fi


This is trying to figure out whether any arguments were provided after:

. "$path/autoload.bash"
>

It can't simply look at "$@" because when *no* args are given, the outer
args are left bound to "$@" (and can be modified by shift & set).

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. That's where the test for BASH_SOURCE[0] == BASH_ARGV[0] is
needed. It's still only probabilistic, because BASH_ARGV & BASH_ARGC have
some other weird behaviours, but it has a higher likelihood of being
correct, and in the cases where it's giving a false nagative, the
parameters would be invalid for my use case.

This test will clearly break if BASH_SOURCE does not contain exactly the
parameter given to "source" (or ".").

However this kludge is only necessary because of the pollution of
BASH_ARGC/BASH_ARGV, and my test will work correctly if that pollution is
removed.

I would be happy to always have $(realpath $0) or $(realpath
$sourced_filename) in BASH_SOURCE if there was also a concomitant change to
preface '0' onto ARGC (and not change BASH_ARGV) when a file is sourced (or
a function is called) without any args. However I worry that the latter
change might adversely affect someone else's code.

-Martin



On Thu, 27 Jun 2024 at 00:17, 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 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
>
>>


Re: proposed BASH_SOURCE_PATH

2024-06-26 Thread Léa Gris

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 0 is a very different semantic than 
BASH_SOURCE. I don't even understand why BASH_SOURCE would point to 
anything other than the source path or the real source path if some 
option tells it to resolve real paths.


--
Léa Gris



Re: proposed BASH_SOURCE_PATH

2024-06-26 Thread konsolebox
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 people wouldn't want to implement BASH_SOURCE values
being resolved to real path by default, Bash can store the working
directories to another list like "BASH_SOURCE_PWD".  Then if someone
wants to get the real path version of a value in BASH_SOURCE, they can
do so either by:

1) Enabling a shell option.  All values in BASH_SOURCE will be
recalculated to their real path versions and all new values will be
stored as real paths from now on.
2) Accessing BASH_SOURCE_REAL instead.  The values of BASH_SOURCE_REAL
are initially empty and are only calculated the moment they are
accessed.

I still prefer the simpler one however, which is to just assign real
paths to BASH_SOURCE by default.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-06-26 Thread Chet Ramey

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'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/




Re: proposed BASH_SOURCE_PATH

2024-06-26 Thread Martin D Kealey
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 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

>


Re: proposed BASH_SOURCE_PATH

2024-06-26 Thread konsolebox
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 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

It's pretty simple but I wonder if an error should be raised if for
some reason sh_realpath fails.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-06-25 Thread Chet Ramey

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 to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/




Re: proposed BASH_SOURCE_PATH

2024-06-25 Thread Chet Ramey

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 penalizing code that does not need
it.


I'll consider these for a future version.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/




Re: proposed BASH_SOURCE_PATH

2024-06-21 Thread konsolebox
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 need it.

You can also just add another option that enables it.  Just make sure
the script that enables the option also gets its own real path and not
only the ones that get source'd after it.

Lazily resolving the script's real path also means you have to store
the context directories to another list.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-06-21 Thread Martin D Kealey
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" to reduced to
simply

  SOURCE_PATH=

or in more complex situations perhaps
  SOURCE_PATH+=:˜./lib:˜./../lib

so that

  . module.bash

will read "module.bash" from a location relative to the current file,
without regard for $PWD or $PATH.

The short preamble "SOURCE_PATH=" relies on a (proposed) rule that when
SOURCE_PATH contains an empty element, it is treated as equivalent to "˜.".

(It could be argued that an explicit syntax such as
SOURCE_PATH=${BASH_SOURCE[0]@R@D} would be more general, and I would favour
also implementing those modifiers, but it's also a well understood
engineering principle that we should make systems so that it's easier to do
the "best thing" or "right thing". Also unknown ˜ expansions will pass
through unchanged on any version of Bash that does not understand them,
whereas ${var@R@D} will provoke a syntax error.)

The new ˜ expansion forms are ~@[DIGITS] and ~.[DIGITS] (where [DIGITS]
denotes zero or more decimal digits). The ~@ form expands to a "partially
normalised form" of an selected path as explained below. The ~. form
expands to the dirname of the corresponding ~@ form.

I defined this "partially normalised form" as approximating what "realpath"
provides, but with weaker guarantees: the basename of the expansion is
guaranteed to be the final value after resolving symlinks, but the path
before that may be any path that is functional, especially if $PWD is
inaccessible. In particular it may not be an absolute path, or might start
with a prefix like /proc/1234/fd/99/.

With no digits, ~@ expands to a partially normalised path to the current
file, ${BASH_SOURCE[0]}.

When zero, ~@0 expands to a partially normalised $0.

Otherwise ~.NUMBER expands to a partially normalised form of
${BASH_SOURCE[NUMBER]}. (This might be omitted from the initial
implementation; we probably need more experience to see if it's actually
useful.)

-Martin

On Thu, 20 Jun 2024, 10:12 konsolebox,  wrote:

> 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_PATH}/../lib/foo.sh"
>
> You misunderstood the use of BASH_SOURCE_PATH though.  It's proposed
> to be an alternative to PATH which is only respected by source.  I
> suggest another name.  And that is BASH_SOURCE_REAL.
>
> Alternatively, have BASH_SOURCE always produce real physical paths
> either by default or through a shopt.
>
> Any additional feature that doesn't allow loading a script relative to
> the caller without external help is practically useless.
>
>
> --
> konsolebox
>
>


Re: proposed BASH_SOURCE_PATH

2024-06-21 Thread alex xmb sw ratchev
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 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.
>
> 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 directory (e.g. `bash main.sh`) you would end up
> with an invalid path (e.g. main.sh/../lib/foo.sh).
>
> To solve such a seemingly simple problem when first introduced to Bash, I
> turned to StackOverflow. Note this question has hundreds of answers of
> varying complexity with thousands of up and downvotes. Yikes!
>
>
> https://stackoverflow.com/questions/59895/how-do-i-get-the-directory-where-a-bash-script-is-located-from-within-the-script
>
> 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’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:
>
> source -- "$(dirname -- "${BASH_SOURCE[0]}")/../lib/foo.sh"
> source -- "$(dirname -- "${BASH_SOURCE[0]}")/../lib/foo.sh"
> ...
>
> I would love to be able to do this for efficiency and readability (see
> below). This would prevent future users from having to sift through
> hundreds of faulty StackOverflow answers like I did.
>
> source -- "${BASH_SOURCE_PATH}/../lib/foo.sh"
> source -- "${BASH_SOURCE_PATH}/../lib/bar.sh"
> ...
>
> -Will
>
>
>


xmb.mepath
Description: Binary data


Re: proposed BASH_SOURCE_PATH

2024-06-20 Thread Oğuz
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

2024-06-20 Thread Léa Gris

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 valid option, then to make BASH_SOURCE contain the real 
path in all circumstances?


--
Léa Gris



Re: proposed BASH_SOURCE_PATH

2024-06-19 Thread Oğuz
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 directory (e.g. `bash main.sh`) you would end up
> with an invalid path (e.g. main.sh/../lib/foo.sh).
>

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.


-- 
Oğuz


Re: proposed BASH_SOURCE_PATH

2024-06-19 Thread Will Allan via Bug reports for the GNU Bourne Again SHell
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 substitution in each 
of my main scripts.

Note that ShellCheck uses a similar SCRIPTDIR to help locate sourced files 
relative to the main script:

https://github.com/koalaman/shellcheck/issues/1577

-Will

On Wednesday, June 19, 2024 at 03:13:59 PM PDT, konsolebox 
 wrote: 





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_PATH}/../lib/foo.sh"


You misunderstood the use of BASH_SOURCE_PATH though.  It's proposed
to be an alternative to PATH which is only respected by source.  I
suggest another name.  And that is BASH_SOURCE_REAL.

Alternatively, have BASH_SOURCE always produce real physical paths
either by default or through a shopt.

Any additional feature that doesn't allow loading a script relative to
the caller without external help is practically useless.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-06-19 Thread konsolebox
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_PATH}/../lib/foo.sh"

You misunderstood the use of BASH_SOURCE_PATH though.  It's proposed
to be an alternative to PATH which is only respected by source.  I
suggest another name.  And that is BASH_SOURCE_REAL.

Alternatively, have BASH_SOURCE always produce real physical paths
either by default or through a shopt.

Any additional feature that doesn't allow loading a script relative to
the caller without external help is practically useless.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-06-19 Thread konsolebox
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 you only need to load a single script.  For example:

source "$(realpath -m "${BASH_SOURCE}/../../lib/script.bash")" || exit


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-06-19 Thread Will Allan
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
  SCRIPT_DIR="."
fi

-Will




On Wednesday, June 19, 2024 at 02:08:27 PM PDT, Koichi Murase 
 wrote: 





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 contain a
slash when the script is specified as e.g. `bash a.sh' or `source
a.sh'.


> [...] it is not system agnostic anymore.


POSIX 2024 containing realpath(1) was just published, though I'm not
sure when/whether it will be available in very old systems.

--
Koichi




Re: proposed BASH_SOURCE_PATH

2024-06-19 Thread Koichi Murase
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 contain a
slash when the script is specified as e.g. `bash a.sh' or `source
a.sh'.

> [...] it is not system agnostic anymore.

POSIX 2024 containing realpath(1) was just published, though I'm not
sure when/whether it will be available in very old systems.

--
Koichi



Re: proposed BASH_SOURCE_PATH

2024-06-19 Thread Léa Gris

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’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:

source -- "$(dirname -- "${BASH_SOURCE[0]}")/../lib/foo.sh"
source -- "$(dirname -- "${BASH_SOURCE[0]}")/../lib/foo.sh"


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]%/*}

Now indeed this does not solve symbolic links and to do this, you need a 
sub-shell and it is not system agnostic anymore.


realSource=$(realpath -- "${BASH_SOURCE[0]}") && 
realScriptDir=${realSource%/*}





--
Léa Gris



Re: proposed BASH_SOURCE_PATH

2024-06-19 Thread Will Allan
> 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.

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 directory (e.g. `bash main.sh`) you would end up with an 
invalid path (e.g. main.sh/../lib/foo.sh).

To solve such a seemingly simple problem when first introduced to Bash, I 
turned to StackOverflow. Note this question has hundreds of answers of varying 
complexity with thousands of up and downvotes. Yikes!

https://stackoverflow.com/questions/59895/how-do-i-get-the-directory-where-a-bash-script-is-located-from-within-the-script

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’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:

source -- "$(dirname -- "${BASH_SOURCE[0]}")/../lib/foo.sh"
source -- "$(dirname -- "${BASH_SOURCE[0]}")/../lib/foo.sh"
...

I would love to be able to do this for efficiency and readability (see below). 
This would prevent future users from having to sift through hundreds of faulty 
StackOverflow answers like I did.

source -- "${BASH_SOURCE_PATH}/../lib/foo.sh"
source -- "${BASH_SOURCE_PATH}/../lib/bar.sh"
...

-Will




Re: proposed BASH_SOURCE_PATH

2024-05-18 Thread konsolebox
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 $PWD
>>
>> Not to $PWD but the calling script's directory.  source as it is now
>> already refers to $PWD.  `source -i` will refer to the calling
>> script's directory instead.
>
>
> Ok, that seems more reasonable, and seemingly parallels the supposed (*) 
> special-case behaviour of './' elsewhere.
>
>> > * a and b/c/d (any paths not starting with '/' or './') would remain as I 
>> > specified, and be treated as relative to $(dirname $(realpath $0))
>>
>> Only if BASH_SOURCE_PATH is empty will $0 be used as reference because
>> it becomes the default as you have suggested.  But if it isn't, the
>> paths specified in BASH_SOURCE_PATH will be used instead.
>
>
> Strongly agreed; I over-simplified my description.
>
>> `cmd` searches for the binary in PATH, `./cmd` doesn't.
>> `source script` searches for the script in PATH.  `source ./script` doesn't.
>
>
> Yes I get that, but that's because ./script is a particular case of 
> subdir/script, and in POSIX subdir/script isn't searched for. (Supposedly 
> that behaviour is different when not in POSIX mode, but I couldn't confirm 
> that experimentally.)
>
>> Why would you decide to change `source -i ./script` to also search for
>> the script in BASH_SOURCE_PATH just because a bunch of newbies might
>> misinterpret it?
>
>
> To be clear, I was suggesting that "modulegroup/module.bash" should search 
> BASH_SOURCE_PATH; my fairly weak objection was to treating "./module.bash" 
> differently based on its textual form, but it's not the hill I want to die 
> on. If there's precedent elsewhere then I withdraw that objection.
>
> I wonder whether 'source -i' should ignore POSIX mode and behave as if it's 
> always "on"?
>
>> Even without considering source and "cmd"'s current behavior, it
>> doesn't make sense to add an additional option just to make the shell
>> know that you're referring to an explicit path relative to the current
>> directory (or script) or not.
>
>
> Put that way, it does sound a bit odd.
>
>> Also just to make sure things are clear.  I'm referring to "$0" here
>> as the main script's path and not the calling script's path.
>> BASH_SOURCE_PATH can be allowed to have a default value but it doesn't
>> make sense if that "default value" changes meaning depending on the
>> location of the script running.  BASH_SOURCE_PATH's values are
>> supposed to always refer to the same paths regardless if the values
>> are relative or not otherwise that would be a broken behavior.
>> Relative paths in BASH_SOURCE_PATHS if they become allowed should use
>> the main script's directory as reference as well.
>
>
> Hmm, I can see cases for both relative to $0 and relative to whichever file 
> contains the "source" command.
> Is there a consensus on this?

I don't know.  I didn't get a direct reply on this besides yours yet
and I haven't thoroughly read the other thread.  I just think it's the
most sensible way to do it if ever default values and relative paths
in BASH_SOURCE_PATH become supported.

I also now think it's better to not support them at all since the main
script itself is not a reliable reference.  Relying on PWD makes it
worse as well.  Scripts less likely changing directories while calling
`source -i` is not a valid reason to use it.  `source -i` has to work
consistently through and through in all cases.

Please make sure you reply to bug-bash as well and not just to me.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-05-16 Thread Chet Ramey

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'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: proposed BASH_SOURCE_PATH

2024-05-16 Thread Chet Ramey

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 `invisible' action? You have to actually set the variable to use it.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: proposed BASH_SOURCE_PATH

2024-05-16 Thread alex xmb sw ratchev
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=${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, 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
 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.

>>>
>>>  [[ $BASH_SOURCE == /* ]] &&
>>> medir=${BASH_SOURCE%/*} ||
>>> medir=$PWD/${BASH_SOURCE%/*}
>>>
>>> declare -p medir
>>>
>>
>> sorry there is bug ..
>>
>>
>>> This feature request sounded promising at first, it feels like
 bike-shedding now.


 --
 Oğuz

>>>


Re: proposed BASH_SOURCE_PATH

2024-05-16 Thread alex xmb sw ratchev
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, 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
>>> 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.
>>>
>>
>>  [[ $BASH_SOURCE == /* ]] &&
>> medir=${BASH_SOURCE%/*} ||
>> medir=$PWD/${BASH_SOURCE%/*}
>>
>> declare -p medir
>>
>
> sorry there is bug ..
>
>
>> This feature request sounded promising at first, it feels like
>>> bike-shedding now.
>>>
>>>
>>> --
>>> Oğuz
>>>
>>


Re: proposed BASH_SOURCE_PATH

2024-05-16 Thread alex xmb sw ratchev
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?
>>
>>
>> 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.
>>
>
>  [[ $BASH_SOURCE == /* ]] &&
> medir=${BASH_SOURCE%/*} ||
> medir=$PWD/${BASH_SOURCE%/*}
>
> declare -p medir
>

sorry there is bug ..


> This feature request sounded promising at first, it feels like
>> bike-shedding now.
>>
>>
>> --
>> Oğuz
>>
>


Re: proposed BASH_SOURCE_PATH

2024-05-16 Thread alex xmb sw ratchev
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
> 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.
>

 [[ $BASH_SOURCE == /* ]] &&
medir=${BASH_SOURCE%/*} ||
medir=$PWD/${BASH_SOURCE%/*}

declare -p medir

This feature request sounded promising at first, it feels like
> bike-shedding now.
>
>
> --
> Oğuz
>


Re: proposed BASH_SOURCE_PATH

2024-05-16 Thread Oğuz
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 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.


-- 
Oğuz


Re: proposed BASH_SOURCE_PATH

2024-05-16 Thread Martin D Kealey
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 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]}).
>
> 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, files to be sourced in
> somewhere/lib, and so on?
>

On the contrary, I would expect a typical setting to be something like
 BASH_SOURCE_PATH=../lib:../config
Or alternatively, that people will write:
 source -i ../lib/module.bash
 source -i ../config/theproject.conf
making use of the implicit '.' when BASH_SOURCE_PATH is unset or empty.


> > 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.
>
> Is this pattern really common enough to break with existing behavior like
> you propose?
>

It's something that people try to do often enough that there's a HOWTO for
it Greg's Bash FAQ, and a bot auto-response in ircs:irc.libera.chat#bash.

And sadly, people do indeed often make scripts that are brittle or outright
broken because they assume $(dirname $0) == '.'
Just search for how many shell scripts suggest using './name' to invoke
them.

To be fair, the commonest case is looking for a "configuration file",
rather than a collection of modules

But yes, unpacking any tarball or cloning any git repo will result in a
directory tree grafted to a random point in the filesystem, and it'll stay
that way if it doesn't have an explicit installation procedure (such as
"make install").


You also suggested not having '-i' and just enabling the new behaviour when
BASH_SOURCE_PATH is set.
I strongly disagree with this for two reasons.
(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.
(2) We want it to fail with 'source: can't file "-i"' when run on a version
of Bash that can't provide this suppression.

-Martin


Re: proposed BASH_SOURCE_PATH

2024-05-16 Thread konsolebox
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 perhaps "skip path searching" 
>> > should be controlled by a separate switch, perhaps '-s'?
>>
>> No. `source` already searches PATH when ./ isn't provided. That's already 
>> intuitive.
>
>
> We were discussing what happens with the proposed `source -i` which doesn't 
> look at PATH at all, with my additional proposed that it would only skip 
> searching BASH_SOURCE_PATH when the name doesn't start with '/', and moreover 
> that it would behave as if CWD=$(dirname $(realpath $0)) for the purpose of 
> resolving any relative path in BASH_SOURCE_PATH (including the implicit '.' 
> when it's empty).
>
> As I understood your counter-proposal, it would result in this:
> * ./a and ./b/c/d would be treated as relative to $PWD

Not to $PWD but the calling script's directory.  source as it is now
already refers to $PWD.  `source -i` will refer to the calling
script's directory instead.

> * a and b/c/d (any paths not starting with '/' or './') would remain as I 
> specified, and be treated as relative to $(dirname $(realpath $0))

Only if BASH_SOURCE_PATH is empty will $0 be used as reference because
it becomes the default as you have suggested.  But if it isn't, the
paths specified in BASH_SOURCE_PATH will be used instead.

> * /x/y/z would still be used as-is (no change)
> If I've misunderstood your counterproposal, please explain further.
>
> In response to this, I contend that changing behaviour depending on a textual 
> prefix (that appears to be a normal path) seems unwise to me. At the very 
> least it should be marked in a way that indicates it's an expansion, such as 
> with '~' or '$'. Or simply provide another option to 'source' to control this.

`cmd` searches for the binary in PATH, `./cmd` doesn't.
`source script` searches for the script in PATH.  `source ./script` doesn't.

Why would you decide to change `source -i ./script` to also search for
the script in BASH_SOURCE_PATH just because a bunch of newbies might
misinterpret it?  Are you implying to take the opportunity to "fix"
the supposedly unintuitive behavior which is actually intuitive and
make people need to remember that `source -i` differs from source and
"cmd" when it comes to searching for scripts using relative paths?
The obvious and ridiculous thoughts on this would be "it's already
different anyway".  I'm talking about the fundamental pattern on how a
relative path is treated - by default.  Not with any additional
option.

Even without considering source and "cmd"'s current behavior, it
doesn't make sense to add an additional option just to make the shell
know that you're referring to an explicit path relative to the current
directory (or script) or not.

> Lastly, I note that a very large number of scripts out on the internet only 
> work correctly when invoked with (cd /path && ./name) because they tacitly 
> assume that $(dirname $0) is '.', particularly when loading modules or 
> configuration files, and will break if invoked as /path/name from a different 
> directory.
>
> Changing the relative base from $PWD to $(dirname $0) goes a little way 
> towards improving that situation; we can simply tell novice programmers to 
> use 'source -i' instead of 'source', and it will just work; they don't need 
> to include six extra lines of arcane magic that they don't understand, and 
> they don't even need to set BASH_SOURCE_PATH (since empty or unset is 
> equivalent to '.', meaning $(dirname $(realpath $0))).
>
> There is precedent in the Linux kernel (and elsewhere) for relative paths NOT 
> being relative to $PWD; the openat(2) syscall allows the caller to provide a 
> filedescriptor connected to any directory, and indeed I suggest the 
> implementation should make use of this, rather than messing with path 
> concatenation.

I'm not sure what to comment on those.

Also just to make sure things are clear.  I'm referring to "$0" here
as the main script's path and not the calling script's path.
BASH_SOURCE_PATH can be allowed to have a default value but it doesn't
make sense if that "default value" changes meaning depending on the
location of the script running.  BASH_SOURCE_PATH's values are
supposed to always refer to the same paths regardless if the values
are relative or not otherwise that would be a broken behavior.
Relative paths in BASH_SOURCE_PATHS if they become allowed should use
the main script's directory as reference as well.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-05-16 Thread Martin D Kealey
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 $PWD.
>
> [...]
>
However, I think what is generally achieved by proposal 1 would be
>
>   source "$__dir__/ BASH_SOURCE_PATH>/xxx/yyy/libzzz.bash"
>
> This might be useful when the middle path elements of the library
> location are ambiguous, yet the candidates are common with different
> $__dir__. However, I don't have an idea about whether this has a
> significant demand. What would be the use case? I naively think only
> `.' is normally useful for the suggested interpretation of relative
> paths.
>

That's fairly accurate.
I would expect there would normally be only one, but the utility is that it
can go anywhere between absolute paths, not just first or last.
It also leads automatically to (what I consider) the optimal result when
BASH_SOURCE_PATH is empty or unset.

A more sophisticated usage might be to load both "modules" and
"configuration settings" the same way:

BASH_SOURCE_PATH=../lib:/usr/share/fubar/bash-lib:${XDG_CONFIG_HOME:-$HOME/.local/config}/fubar/config:../config:/usr/share/fubar/config
source -i module1.bash
source -i custom_module.bash
source -i fubar.config

-Martin


Re: proposed BASH_SOURCE_PATH

2024-05-15 Thread Greg Wooledge
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 suspect that almost all use of '.' is for people writing
> a bunch of scripts for personal use, which use a set of common functions
> that that suit the needs of the person writing the script

There is one extremely noteworthy example of '.' being used in production
shell scripts: System V rc scripts on Linux systems.

As just one example, the /etc/init.d/cron script shipped with Debian's
cron package dots in /lib/lsb/init-functions very early.  This model
of "helper functions commonly used by a bunch of related scripts" is
prevalent in many Linux distributions' sysv-rc scripts, where such
scripts still exist at all.

This same script also contains the following line:

[ -r /etc/default/cron ] && . /etc/default/cron

This is another common practice in Linux sysv-rc scripts.  The files in
/etc/default/ are dottable shell fragments used to set configuration
variables.  They're intended to be user editable.

You'll note that both of the files being dotted in by this script are
absolute pathnames.  I am not aware of *any* scripts that use relative
paths and the $PATH variable to search for files to be dotted in.  I
can't say *nobody* does it, but I don't recall seeing it.



Re: proposed BASH_SOURCE_PATH

2024-05-15 Thread Robert Elz
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, files to be sourced in
  | somewhere/lib, and so on?

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 suspect that almost all use of '.' is for people writing
a bunch of scripts for personal use, which use a set of common functions
that that suit the needs of the person writing the script (so that
their common functions can be used without thought) - I have a bunch of
those in one file that I use all over the place, and another file that
has functions only useful in interactive shells, and one or two more
that have functions with more specialised uses.   Of course, I know
exactly where all those files are stored, and I just use ". /path/to/files"
(or more commonly ". "${FP}/..." to make it easier to modify if needed).
(and no, I don't use "FP", that's just an illustration.)

If I were ever to distribute any of these scripts, which isn't all that
likely, I'd simply find the '.' commands and include the functions that
are needed from the file, instead of the '.' command, and send away that
version (then there's no issue of the two different files diverging,
which could happen if a replacement for the script was sent, and that
some function in the included file had changes was forgotten).

If someone were to distribute a script, with script fragments in
different files (probably because there are actually several scripts
which share a set of functions) then it is very unlikely that they'd
rely upon the user (or package maker) following any set convention
for where things should be installed - everyone has their own way of
doing that, and puts things in different places.  For that, the sane
thing to do is have the script do

. "%%SCRIPT_DIR%%/funcs1.sh"
. "%%SCRIPT_DIR%%/fs-funcs/listings.sh"

(etc)

and provide a simple sed script which replaces %%SCRIPT_DIR%%
with the whatever (full) path name is that the user (or packager)
actually uses to place those files into.

All this "path searching" stuff is really unnecessary for the '.'
command, as no-one really needs to use it, except in fictional
environments that don't really exist.   That's why no-one really
even notices that the standard '.' command searches PATH for
simple filenames - because in practice, no-one ever does that.

That's why I really don't think any of this is particularly useful.

It's also I don't much care if a different path-like searching
method is defined, because I don't really think that almost anyone
would use that either.

kre




Re: proposed BASH_SOURCE_PATH

2024-05-15 Thread Chet Ramey

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.


This implies only the directory where the main script is located will
be used, correct?

Hopefully Bash already has a deterministic way of knowing the
directory the main script is located.


How deterministic do you need? Bash sets $0 and ${BASH_SOURCE[0]} to the
script name passed as an argument. It's easy enough to write a function
that canonicalizes that, or to use `realpath' as others have suggested.
(There is a `realpath' loadable builtin.)

Once you've canonicalized it, you can use ${FULLPATH%/*} to get the
directory name.




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.  Paths beginning with ./ or ../ should be
considered explicit and not searched in BASH_SOURCE_PATH.


Those are absolute pathnames.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/




Re: proposed BASH_SOURCE_PATH

2024-05-15 Thread Chet Ramey

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 locating the
library files whose paths are only known relative to $0 (or
${BASH_SOURCE[0]}).


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, files to be sourced in
somewhere/lib, and so on?



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.


Is this pattern really common enough to break with existing behavior
like you propose?

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/




Re: proposed BASH_SOURCE_PATH

2024-05-15 Thread Chet Ramey

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.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/




Re: proposed BASH_SOURCE_PATH

2024-05-15 Thread Koichi Murase
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 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.

After thinking about it again, I'm wondering what would be the assumed
use case of proposal 1 for the relative paths in BASH_SOURCE_PATH. I
think a way to simplify

  source "$__dir__/xxx/yyy/libzzz.bash"

(where $__dir__ is resolved to be the location of the current script
file) would be useful. However, I think what is generally achieved by
proposal 1 would be

  source "$__dir__//xxx/yyy/libzzz.bash"

This might be useful when the middle path elements of the library
location are ambiguous, yet the candidates are common with different
$__dir__. However, I don't have an idea about whether this has a
significant demand. What would be the use case? I naively think only
`.' is normally useful for the suggested interpretation of relative
paths.



Re: proposed BASH_SOURCE_PATH

2024-05-15 Thread Koichi Murase
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.
>
> declare -g -A __sourced__files__
> __sourced__files__[$BASH_SOURCE]=$(realpath "$BASH_SOURCE")
> # This is to ensure to the relative path is to the actual bash file
> instead of a symlink to the bash file.
> source 
> "${__sourced__files__[$BASH_SOURCE]%/*}/dirname1/dirname2/${BASH_SOURCE##*/}"
> # My convention is that the file sourced in the subdirectory has the
> same filename as the parent file.
> # The difference between them are expressed in the directory path,
> i.e., dirname1/dirname2

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.

By the way, I got an inspiration from your example. You can define
name references to automate the resolution of the directory. With the
following definitions somewhere in a framework:

  declare -gA _Impl_file _Impl_dir _Impl_empty
  declare -gn 
__file__='_Impl_file[${_Impl_empty[x${_Impl_file[${BASH_SOURCE-$0}]=$(realpath
"${BASH_SOURCE-$0}")}]-}${BASH_SOURCE-$0}]'
  declare -gn 
__dir__='_Impl_dir[${_Impl_empty[x${_Impl_dir[${BASH_SOURCE-$0}]=$(dirname
"$__file__")}]-}${BASH_SOURCE-$0}]'

you can simply call

  source "$__dir__/xxx/yyy/libzzz.bash"

in each file intended to be sourced. The value of __dir__ always
reflects the location of the current script file. The names of the
variables can be adjusted to suit your taste.



Re: proposed BASH_SOURCE_PATH

2024-05-15 Thread Chet Ramey

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 lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/




Re: proposed BASH_SOURCE_PATH

2024-05-14 Thread konsolebox
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 PATH when ./ isn't provided.  That's
already intuitive.

In C, you don't specify ./ as well when referring to relative paths in
#include.  No one should ever get used to using ./ when referring to
relative paths.


-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-05-14 Thread Peng Yu
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 to $PWD.
> >
> > As an interim step until that's implemented, please ignore any relative
> > entries in BASH_SOURCE_PATH, so that users who really want the cwd in
> > BASH_SOURCE_PATH get used to writing $PWD or /proc/self/cwd instead.
>
> 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.

declare -g -A __sourced__files__
__sourced__files__[$BASH_SOURCE]=$(realpath "$BASH_SOURCE")
# This is to ensure to the relative path is to the actual bash file
instead of a symlink to the bash file.
source 
"${__sourced__files__[$BASH_SOURCE]%/*}/dirname1/dirname2/${BASH_SOURCE##*/}"
# My convention is that the file sourced in the subdirectory has the
same filename as the parent file.
# The difference between them are expressed in the directory path,
i.e., dirname1/dirname2

My concern with adding too many features in bash is that it may have a
maintenance problem and backward compatibility issues.

Python has this problem. Python2 was good, but they introduced python3
which supposedly to make it better. But python3 introduced too many
problems. One problem is it is very difficult to import a python file
at an arbitrary location in Python3. There are too many redundant
features in Python 3, it is unclear which one is more stable then the
other. Sometimes, a feature is removed in newer version of Python
which breaks my programs that used to work. This increases maintenance
costs.

In this case, my above method works fine for many years. It sounds to
me like adding a new feature for a relative source is unnecessary.

> * One concern with treating relative paths relative to the current
> script location is that the user might put `.' in BASH_SOURCE_PATH to
> mean the current directory. I don't think it is a good practice, but I
> anticipate that users expect that. For example, one can observe the
> default values of PATH [1] and BASH_LOADABLES_PATH [2] in the Bash
> codebase. It explicitly contains `.' to mean the current working
> directory. It is very confusing that `.' in BASH_SOURCE_PATH points to
> the script location ($(dirname ${BASH_SOURCE[0]})), while `.' in PATH
> and BASH_LOADABLES_PATH points to the current working directory
> ($PWD).
>
> [1] 
> https://git.savannah.gnu.org/cgit/bash.git/tree/config-top.h?h=devel=b3d8c8a4e7c5417d986f93f646ea740cb13c08d7#n61
> [2] 
> https://git.savannah.gnu.org/cgit/bash.git/tree/config-top.h?h=devel=b3d8c8a4e7c5417d986f93f646ea740cb13c08d7#n78
>
> One solution might be to treat `.' as a special case to mean $PWD, and
> the other relative paths would mean the path relative to the script
> location. However, the problem is that it is confusing that the base
> location changes depending on its form. In particular, the difference
> in the behavior between `.' and `..' would be very confusing.
>
> Another solution would be to introduce a special name to mean the
> current script location. For example, we could introduce a tilde
> expansion to mean the current script location since the only expansion
> processed in `find_path_in()' and related functions is the tilde
> expansion. We already have ~+ and ~+N (equivalently, ~N) to mean
> ${DIRSTACK[N]}. Similarly, we can have e.g. ~@  and ~@N to mean
> $(dirname ${BASH_SOURCE[N]}). This can also be useful outside
> BASH_SOURCE_PATH since determining the directory name of a path isn't
> just ${path%/*} and one needs to care about edge cases to properly do
> that.
>
> * Another point to discuss is whether we should resolve the symbolic
> links. Maybe it's just fine to resolve the symbolic links fully (as
> suggested), but another possibility can be to search all the
> directories appearing in the intermediate steps of the link
> resolution.
>
> > 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 agree. I actually thought about raising the discussion about this
> after the current patch set is merged.
>
> > 3. To avoid accidentally loading a script rather than a library, while
> > searching BASH_SOURCE_PATH, ignore any files that have exec permission,
> > inverting the check normally made for executables in PATH. This would keep
> > executables and libraries functionally separate, even if they're commingled
> > in the same directories.
>
> I disagree with this. Since the original intent of having
> BASH_SOURCE_PATH would be to have the list of directories that do not
> contain files not intended to be sourced, I don't see a reason to
> perform additional filtering. I generally think that 

Re: proposed BASH_SOURCE_PATH

2024-05-14 Thread Martin D Kealey
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.  Paths beginning with ./ or ../ should be
> considered explicit and not searched in BASH_SOURCE_PATH.
>
> It should use the directory of the calling script as reference when
> using -i or $PWD when not.
>

For the particular cases of './' and '../' that seems reasonable when the
fallback is the location of the script (proposal 4), but in general I would
prefer "source -i foo/bar/zing" to honour BASH_SOURCE_PATH.

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'?

Yes one could instead write "BASH_SOURCE_PATH='' source -i ...", but that
would mess up the search path for inner source commands, and avoiding that
is one of the reasons for doing this in the first place. (And yet again I'm
wishing that "local" could be used outside functions.)

-Martin


Re: proposed BASH_SOURCE_PATH

2024-05-14 Thread Léa Gris


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 folders
mkdir -p ./tests/libs

# Create main bash script command
cat > ./tests/real_bash_source_dir_test <<'BASH'
#!/usr/bin/env bash
real_source=$(realpath "${BASH_SOURCE[0]}")
real_source_dir=${real_source%/*}
include_path=$real_source_dir/libs

# shellcheck source=./libs/testlib.bash
source "$include_path/testlib.bash" || exit 1 # cannot load library
TestLib::hello
BASH

# Make it executable
chmod +x ./tests/real_bash_source_dir_test

# Create symbolic link to executable
ln -frs ./tests/real_bash_source_dir_test ./

# Create the library
cat > ./tests/libs/testlib.bash <<'BASH'
(return 0 2>/dev/null) && [ -n "${BASH_VERSION}" ] || exit 1
TestLib::hello() { printf 'Hello from TestLib\n';}
BASH

# Run command script from its real install dir
./tests/real_bash_source_dir_test

# Run command script from its symbolic link in current dir
./real_bash_source_dir_test

You can see it is able to source its library relative to its real 
installed path and it works regardless of if called from a symbolic link 
or directly from its installed dir.


--
Léa Gris


Re: proposed BASH_SOURCE_PATH

2024-05-14 Thread Léa Gris

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 problem locating the
library files whose paths are only known relative to $0 (or
${BASH_SOURCE[0]}).


This needs to resolve symbolic links otherwise path will be that of the 
symbolic link rather than that of the actual script file:


mkdir ./tests/
cat > ./tests/real_bash_source_dir_test <<'BASH'
#!/usr/bin/env bash
real_source=$(realpath "${BASH_SOURCE[0]}")
real_source_dir=${real_source%/*}
printf 'Real Bash source dir: %s\n' "$real_source_dir"
BASH
chmod +x ./tests/real_bash_source_dir_test
ln -sr ./tests/real_bash_source_dir_test ./


Then you get same answer in both cases:
./tests/real_bash_source_dir_test
./real_bash_source_dir_test

--
Léa Gris


Re: proposed BASH_SOURCE_PATH

2024-05-14 Thread Koichi Murase
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 ignore any relative
> entries in BASH_SOURCE_PATH, so that users who really want the cwd in
> BASH_SOURCE_PATH get used to writing $PWD or /proc/self/cwd instead.

I totally agree that we should have a way to specify the files in
subdirectories by the path relative to the current script file.

* One concern with treating relative paths relative to the current
script location is that the user might put `.' in BASH_SOURCE_PATH to
mean the current directory. I don't think it is a good practice, but I
anticipate that users expect that. For example, one can observe the
default values of PATH [1] and BASH_LOADABLES_PATH [2] in the Bash
codebase. It explicitly contains `.' to mean the current working
directory. It is very confusing that `.' in BASH_SOURCE_PATH points to
the script location ($(dirname ${BASH_SOURCE[0]})), while `.' in PATH
and BASH_LOADABLES_PATH points to the current working directory
($PWD).

[1] 
https://git.savannah.gnu.org/cgit/bash.git/tree/config-top.h?h=devel=b3d8c8a4e7c5417d986f93f646ea740cb13c08d7#n61
[2] 
https://git.savannah.gnu.org/cgit/bash.git/tree/config-top.h?h=devel=b3d8c8a4e7c5417d986f93f646ea740cb13c08d7#n78

One solution might be to treat `.' as a special case to mean $PWD, and
the other relative paths would mean the path relative to the script
location. However, the problem is that it is confusing that the base
location changes depending on its form. In particular, the difference
in the behavior between `.' and `..' would be very confusing.

Another solution would be to introduce a special name to mean the
current script location. For example, we could introduce a tilde
expansion to mean the current script location since the only expansion
processed in `find_path_in()' and related functions is the tilde
expansion. We already have ~+ and ~+N (equivalently, ~N) to mean
${DIRSTACK[N]}. Similarly, we can have e.g. ~@  and ~@N to mean
$(dirname ${BASH_SOURCE[N]}). This can also be useful outside
BASH_SOURCE_PATH since determining the directory name of a path isn't
just ${path%/*} and one needs to care about edge cases to properly do
that.

* Another point to discuss is whether we should resolve the symbolic
links. Maybe it's just fine to resolve the symbolic links fully (as
suggested), but another possibility can be to search all the
directories appearing in the intermediate steps of the link
resolution.

> 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 agree. I actually thought about raising the discussion about this
after the current patch set is merged.

> 3. To avoid accidentally loading a script rather than a library, while
> searching BASH_SOURCE_PATH, ignore any files that have exec permission,
> inverting the check normally made for executables in PATH. This would keep
> executables and libraries functionally separate, even if they're commingled
> in the same directories.

I disagree with this. Since the original intent of having
BASH_SOURCE_PATH would be to have the list of directories that do not
contain files not intended to be sourced, I don't see a reason to
perform additional filtering. I generally think that applications
shouldn't give a new meaning of the executable permission of files for
a purpose different from the original one. They may conflict.

> Yes I know that some folk think it's occasionally useful to have a single
> file that operates as both, but (a) new features should default to the
> "safest" mode of operation, (b) this isn't python and so that's pretty rare
> in practice,

How did you conclude that it's rare? Phi mentioned it. I also have a
script that operates as both. Furthermore, it's actually a recommended
practice by the bpkg manager [3].

[3] https://github.com/bpkg/bpkg?tab=readme-ov-file#packaging-best-practices

For a script file with both usages, I think one wants to put symbolic
links to the file in PATH and BASH_SOURCE_PATH. In such a situation,
the suggested non-executable requirement conflicts with the
requirement for executable files. Do we prohibit the existence of such
a script? Or do we request to make an actual copy or a hard link to
the file (which I think is a bit harder to manage the consistency)? I
think these are unnecessary requirements.

> 4. When using "source -i", if BASH_SOURCE_PATH is unset or empty, it's
> taken as equivalent to '.', so that it's useful to write "source -i
> ../lib/foo.bash" in a script at "$X/bin/bar" to load "$X/lib/foo.bash".

I currently have no particular opinion on this. Maybe I need to think
about it later.



Re: proposed BASH_SOURCE_PATH

2024-05-14 Thread konsolebox
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 the main script is located will
be used, correct?

Hopefully Bash already has a deterministic way of knowing the
directory the main script is located.

> 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.  Paths beginning with ./ or ../ should be
considered explicit and not searched in BASH_SOURCE_PATH.

It should use the directory of the calling script as reference when
using -i or $PWD when not.

> 3. To avoid accidentally loading a script rather than a library, while
> searching BASH_SOURCE_PATH, ignore any files that have exec permission,
> inverting the check normally made for executables in PATH. This would keep
> executables and libraries functionally separate, even if they're commingled
> in the same directories.

This deviates from the known behavior of source and makes it less
intuitive.  It can be useful but it should only be enabled with an
option.

I also don't like seeing my scripts highlighted in executable color in
ls's output when they don't have to be.

> 4. When using "source -i", if BASH_SOURCE_PATH is unset or empty, it's
> taken as equivalent to '.', so that it's useful to write "source -i
> ../lib/foo.bash" in a script at "$X/bin/bar" to load "$X/lib/foo.bash".

I somewhat agree but ./ and ../ should be considered explicit so if
you want lib/foo.bash to load relative to BASH_SOURCE_PATH's ".", just
specify "lib/foo.bash".


-- 
konsolebox

On Tue, May 14, 2024 at 2:09 PM 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 locating the
> library files whose paths are only known relative to $0 (or
> ${BASH_SOURCE[0]}).
>
> 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 ignore any relative
> entries in BASH_SOURCE_PATH, so that users who really want the cwd in
> BASH_SOURCE_PATH get used to writing $PWD or /proc/self/cwd instead.
>
> 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.
>
> 3. To avoid accidentally loading a script rather than a library, while
> searching BASH_SOURCE_PATH, ignore any files that have exec permission,
> inverting the check normally made for executables in PATH. This would keep
> executables and libraries functionally separate, even if they're commingled
> in the same directories.
>
> Yes I know that some folk think it's occasionally useful to have a single
> file that operates as both, but (a) new features should default to the
> "safest" mode of operation, (b) this isn't python and so that's pretty rare
> in practice, and (c) there was at least two work-arounds should that
> behaviour actually be desired: (i) use an absolute path, or (ii) use PATH
> instead of BASH_SOURCE_PATH.
>
> 4. When using "source -i", if BASH_SOURCE_PATH is unset or empty, it's
> taken as equivalent to '.', so that it's useful to write "source -i
> ../lib/foo.bash" in a script at "$X/bin/bar" to load "$X/lib/foo.bash".
>
> -Martin
>
> PS: in the longer term, perhaps PATH could have similar behaviour, but
> gated by a shopt or compat check.



-- 
konsolebox



Re: proposed BASH_SOURCE_PATH

2024-05-14 Thread Matheus Afonso Martins Moreira
Completely agree with your suggestions.
I've proposed suggestion 3 as well in previous
emails but consensus was not reached.

  -- Matheus