[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in pwd
From: |
Jim Meyering |
Subject: |
Re: Bug in pwd |
Date: |
Wed, 16 Feb 2005 16:29:28 +0100 |
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