Re: behavioral change in coreutils `pwd` handling '//' (double slash) caused by gnulib update

[Kaz Kylheku]

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?