On Tue, 4 Feb 2025 at 11:03, Zeffie via Bug reports for the GNU Bourne Again SHell <bug-bash@gnu.org> wrote:
> To address the above points, the following text (or similar language) is > proposed for inclusion in the Bash Reference Manual: > > *[...] * In interactive Bash sessions, any element of the `PATH` variable that > begins with a tilde (e.g., `~` or `~/bin`) is automatically expanded to > the corresponding home directory of the current user at the time a > command is executed. For example, if the user's home directory is > `/home/alice`, then an entry `~/bin` in the `PATH` is interpreted as > `/home/alice/bin` during command lookup. > This description is incomplete. In particular when the initial component of a file path is: - exactly ~, it is replaced by the value of $HOME; - of the form ~username, it is replaced by that user's home directory (obtained by getpwent() or equivalent); - exactly ‘~+’ or ‘~-’, these expand to the values of $PWD and $OLDPWD respectively; These all work both quoted and unquoted in PATH. Rather than recapitulate all these translations that can occur where a tilde is at the start of a pathname, it would be less cumbersome to explain thus: *When a **quoted **tilde-prefix is included in an assignment to PATH and is later used to locate a utility, the same expansions would then occur as would have occurred had it been included unquoted in an assignment to PATH.* If the initial component of a file path begins with ‘~’ but is not of any of the forms given above, the expansion may be used for additional features in future. In that case it would be preferable that they should work both quoted and unquoted. Clearly it is inappropriate to suggest that $HOME be used in place of ‘~’ except where it's a bare ‘~’. It should probably also be pointed out that the parameters upon which a quoted tilde prefix depends may have changed after the assignment, and the effective search path may change accordingly. -Martin PS: POSIX 2024 §2.6.1 <https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_06_01> says > > > > > *A "tilde-prefix" consists of an unquoted <tilde> character at the > beginning of a word, followed by all of the characters preceding the first > unquoted <slash> in the word, or all the characters in the word if there is > no <slash>.[...]If the characters in the tilde-prefix following the <tilde> > form a portable login name, the tilde-prefix shall be replaced by a > pathname of the initial working directory associated with the login name. > The pathname shall be obtained as if by using the getpwnam() function as > defined in the System Interfaces volume of POSIX.1-2024. If the system does > not recognize the login name, the results are unspecified.The pathname that > replaces the tilde-prefix shall be treated as if quoted to prevent it being > altered by field splitting and pathname expansion; [...]* In other words, we're free to add new features, especially if they *don't* look like a portable username. In most shells unrecognized tilde-prefixes (including unknown usernames) are simply left unmodified, but POSIX does not require this. PPS: an example of a possible future feature: I have tentatively proposed that ‘~.’ could expand to the directory containing the file from which commands are currently being read, after symlinks have been resolved. I envisage two principle use-cases for this; both would apply where the script does not have its own absolute path written into it: 1. setting PATH at the start of a script; and 2. accessing an ancillary file adjacent to wherever the script or module is installed, especially modules that can be read using ‘.’ or ‘source’. For a main script this would be similar to ${0%/*} (but without the corner cases), while for sourced modules it would be similar to ${BASH_SOURCE[0]}. Not requiring ‘readlink’ or ‘realpath’ *before* setting PATH would escape a catch-22. PPPS: personally I've never found a use for putting quoted ‘~+» or ‘~-’ in PATH, but I expect someone somewhere will have found uses for them.
