[bug #24949] coreutils pwd not implementing latest POSIX features

[Paul D. Smith]

Follow-up Comment #2, bug #24949 (project coreutils):

The problem is that without -P I can't invoke pwd from things like Perl
portably.  If I use "my $pwd = `pwd`;" and it runs a shell and uses the shell
builtin version of pwd, then I get the wrong thing (I explicitly want the
"real" path; what POSIX defines "pwd -P" to return).

But on the other hand, if I use "my $pwd = `pwd -P`;", which is what a
correct POSIX-conforming script would do, and it runs coreutils pwd instead of
a shell builtin, I get a syntax error.

In short, this is a big drag.

It would be great if, at least, coreutils pwd handled the -P option (since
that's what it does by default it could just accept the option and behave as
it does now).  In other words, I think Reuben Thomas's solution here:
http://lists.gnu.org/archive/html/bug-coreutils/2008-10/msg00259.html is
acceptable.

On the other hand, I think it would not actually be that difficult to
implement -L.  It seems to me that Eric Blake's description of what it would
take to adhere to the POSIX standard, as he describes here:
http://lists.gnu.org/archive/html/bug-coreutils/2008-10/msg00258.html is more
complicated than necessary.  We do not need to strip "." or ".." from the
value of $PWD.  All we need to do is determine if the value of $PWD is (a) an
absolute path, and (b) it refers to the current directory, and (c) it does not
contain "." or ".." as filename elements.  Of these the only tricky bit AFAICS
is (b); we would need to do something like compare the device/inode values of
the directory pointed to by $PWD and the current directory to be sure they had
the same value.  I'm not sure if glib provides this type of functionality.

If all those conditions are met, then "pwd" and "pwd -L" print the value of
$PWD.  If any of those conditions are not met, or if the user asks for "pwd
-P", then we print the absolute pathname determined the same way we determine
it today.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24949>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/