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.
