On 12/29/2012 07:38:24 AM, Felix Janda wrote:
POSIX says that pwd should behave the same as pwd -L. The current
pwd -P should behave the same way as the previous version of pwd.
It
just returns the getcwd() output. pwd -L does just check whether the
environment variable PWD is also a valid current working directory and
uses that instead of the output of getcwd() if that's the case.
Here's a fun corner case:
$ cd
$ mkdir fruit
$ cd fruit
$ (cd .. rmdir fruit)
$ ls -l
total 0
$ pwd
/home/landley/fruit
$ pwd -L
/home/landley/fruit
$ pwd -P
pwd: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
$ pwd -L
pwd: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
$ pwd
pwd: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
The amount of magic inherent in that behavior is kind of mind-boggling.
If you can't getcwd() then it's happy printing $PWD, until you call pwd
-P and that somehow invalidates $PWD? (Which means pwd is totally a
shell builtin because a child process can't persistently set an
environment variable in the parent process).
Sigh. And the whole PWD defaults to -P unless POSIXLY_CORRECT thing
above: while I'm sure that code is in there, it's not actually what
it's doing here. Because GNU code is INSANE, and someone somewhere
thought this tangle of corner cases might help somehow.
Right, in the case of a deleted directory $PWD is all we've got, so
have -L (which is the default) print it but first validate it's an
absolute path with no .. in it. Only validate that current directory
and path directory point to the same place if there IS a current
directory. If that's not what they want, -P exists.
Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
