[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed BASH_SOURCE_PATH
From: |
Koichi Murase |
Subject: |
Re: proposed BASH_SOURCE_PATH |
Date: |
Wed, 15 May 2024 23:48:20 +0900 |
2024年5月14日(火) 15:09 Martin D Kealey <martin@kurahaupo.gen.nz>:
> 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__/<one of relpaths in 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.
- Re: proposed BASH_SOURCE_PATH, (continued)
Re: proposed BASH_SOURCE_PATH, Chet Ramey, 2024/05/15
Re: proposed BASH_SOURCE_PATH, Koichi Murase, 2024/05/14
Re: proposed BASH_SOURCE_PATH, Léa Gris, 2024/05/14
Re: proposed BASH_SOURCE_PATH, Chet Ramey, 2024/05/15
Re: proposed BASH_SOURCE_PATH,
Koichi Murase <=
Re: proposed BASH_SOURCE_PATH, Chet Ramey, 2024/05/15
Re: proposed BASH_SOURCE_PATH, Chet Ramey, 2024/05/16