Re: Bug in pwd

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> POSIX now requires pwd(1) to support -L and -P, that -L is the default,
> and that -L reads $PWD to verify that it is a name (possibly with symbolic
> links) of the current directory.  Coreutils pwd currently implements none
> of this, and behaves as though -P is the default without ever reading $PWD.

Thanks for reporting that.
Do you feel like working on the parts that are possible?

> Furthermore, POSIX requires that when -P is specified, that $PWD be
> updated in the calling environment to scrub all symlinks from the
> environment variable that were previously set by a `cd -L' command.  I see
> no possible way to implement that without relying on pwd(1) being a shell
> builtin.  Bash 3.0 does not do this, I'm filing an additional bug in that
> direction.  Is it worth coreutils even maintaining pwd(1) if it can't be
> fully POSIX-compliant?

Until all shells provide a robust implementation of pwd,
it is most certainly worth it to me.
Try changing to a directory whose absolute name is longer
than PATH_MAX, and then see what your favorite shell's built-in
pwd functions does.  zsh's implementation works.  Bash's does not.

Bash-3.00 gets this:

  shell-init: error retrieving current directory: getcwd: cannot access parent 
directories: File name too long
  pwd: error retrieving current directory: getcwd: cannot access parent 
directories: File name too long