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