Re: proposed BASH_SOURCE_PATH

2024-06-19 Thread Will Allan via Bug reports for the GNU Bourne Again SHell
0, 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

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   SCR

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.

Re: readonly inconsistency with arrays

2024-06-03 Thread Will Allan
-r string="foo" declare -ir int="100" declare -ar array # -Will On Monday, June 3, 2024 at 03:57:23 PM PDT, Zachary Santer wrote: On Mon, Jun 3, 2024 at 6:16 PM Will Allan via Bug reports for the GNU Bourne Again SHell wrote: > > init_vars () {  r

readonly inconsistency with arrays

2024-06-03 Thread Will Allan via Bug reports for the GNU Bourne Again SHell
I'm seeing what appears to be an inconsistency with using `readonly` on variables declared in a previous scope. declare stringdeclare -i intdeclare -a array init_vars () {  readonly string="foo"  readonly int=100  readonly array=(1 2)   # Print the (hopefully) readonly variables  declare -p strin