Re: readlink(1) behavior

[Jim Meyering]

Eric Blake wrote:
> 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).

Yes, that makes sense.

> 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

This would be useful.

> 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/)?

I'd just as soon put this off until after 7.6.
Since this nit is in a corner of a tool isn't even specified
by POSIX, it seems ok to defer it.  But I haven't looked at
what would be involved to fix it.  If the fix is very local and
non-invasive, then maybe.

Besides, I'd like to make a less-stable 7.7 release pretty quickly.