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. 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. $ /bin/pwd /tmp Dash's pwd also produces //pwd So basically, the pwd behavior that a lot of scripts will see on GNU/Linux systems won't be the Coreutils pwd behavior. Moreover, the bug only madde the Coreutils pwd accidentally more compatible with the builtin pwd of two popular shells. > The reproducer is not only > > $ (cd //bin && /coreutils/src/pwd) > > but also > > $ (cd /bin && /coreutils/src/pwd) It looks like the real root cause of this problem isn't a string manpulation problem with slashes, but rather that someone thought it was a good idea to make the library's getcwd function, on Linux, to do something involving reading a symlink under /proc/self/fd, supposedly because it is faster. But, here is a question; if you're going to rely on /proc/self in implementing getcwd, why not just read the /proc/self/cwd symlink? (I wouldn't be rhetorical toward you; maybe there are good reasons!) $ ls -l /proc/self/cwd lrwxrwxrwx 1 kaz kaz 0 Jan 6 15:33 /proc/self/cwd -> /tmp $ pwd //tmp It sanitizes away the extra slash. If that if faster, why wouldn't the system's C library like glibc, musl, ... use this method? In the first place, why does glib provide POSIX functions on platforms where the POSIX C library is under the control of the free software movement?
