On 1/6/25 6:44 PM, Kaz Kylheku wrote:
On 2024-12-31 10:40, Bruno Haible via GNU coreutils General Discussion worote:
Zach van Rijn wrote in
<https://lists.gnu.org/archive/html/bug-gnulib/2023-04/msg00072.html>:
I am investigating a possible regression in gnulib that manifests
as a behavioral change in coreutils `pwd` on some Linux platforms.
Comparing coreutils 9.1 and 9.2 release tarballs, freshly built:
$ x=$(pwd) && (cd //tmp && for k in 9.1 9.2; do echo -n $k:\ &&
${x}/coreutils-$k/src/pwd; done)
9.1: /tmp
9.2: //tmp
Note that the pwd built into (some versions of?) Bash will also report the
double slash.
Because POSIX requires it, at least in this invocation mode.
`pwd' is equivalent to `pwd -L', since that's the default. `pwd -L' is
required to print the value of $PWD, as long as it's an absolute pathname
to the current directory that doesn't contain `.' or `..'. If PWD isn't
exported, of course a separate `pwd' binary is on its own.
PWD is set by `cd'. The POSIX algorithm requires `cd' to leave two
leading slashes unchanged (8c) when performing pathname canonicalization,
and for `cd' to assign that canonicalized pathname to PWD (9).
E.g. a bit dated installation here:
$ cd //tmp
$ builtin pwd
//tmp
$ echo $BASH_VERSION
4.4.20(1)-release
Whereas Coreutils is 8.28 here and /bin/pwd prints /tmp.
Is PWD exported? It usually is.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
