readlink(1) behavior

[Eric Blake]

I think there are some infelicities in the canonicalization options of readlink.

readlink -fv file/    => correctly reports ENOTDIR
readlink -fv missing  => lists /path/to/missing
readlink -fv missing/ => complains that missing is not a dir
readlink -mv file/    => lists /path/to/file
readlink -mv missing/ => lists /path/to/missing

I would like to see: 'readlink -fv missing/' list '/path/to/missing', on the 
grounds that one could do 'mkdir missing' to bring the path into existence; 
this matches the documentation that -f ignores a missing final element (nowhere 
does it say the final element has to be a non-file).

Also, I think that -m should either be changed to reject paths that cannot 
possibly exist given the current state of the file system (that is, in the 
above case, 'readlink -mv file/' should fail with ENOTDIR), or we should create 
a new option (in bewteen -f and -m) with that property.  For an example of how 
this mode might be useful:

Suppose we want to test whether 'mkdir -p a/b && touch a/b/c' will succeed, 
without creating directories if it won't.  'readlink -f a/b/c' is insufficient, 
since a/b might not yet exist.  'readlink -m a/b/c' is insufficient, 
because 'a' might be a regular file or a symlink to itself.

Maybe such an option can be named -p/--possible.

As long as I'm discussing feature requests, it might be nice to add a new 
option -r/--relative, which matches the behavior of Solaris resolvepath in 
giving a relative answer provided the resolution did not leak into a parent 
directory (well, it also matches Solaris 10 realpath, but that violates POSIX 
which requires that realpath always give an absolute answer).  For example:

ln -s b a
ln -s .. c
realpath -f a    => /path/to/b
realpath -r a    => b
realpath -f c    => /path/to
realpath -r c    => /path/to

Are any of these ideas worth dealing with prior to 7.6 (in particular, not 
rejecting -f missing/)?

-- 
Eric Blake