Re: readlink(1) behavior

[Eric Blake]

Jim Meyering <jim <at> meyering.net> writes:

> I'd just as soon put this off until after 7.6.

Agreed; it involves gnulib changes, and it isn't worth holding up the current 
release to change any of this today.

> 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.

Adding -p (or changing the semantics of -m to reject impossible paths) would 
require the addition of another mode to canonicalize_file_mode, which just 
returns on error instead of continuing with //, ., and .. cleanups on the rest 
of the input.  Adding -r would also involve a change to canonicalize_file_mode; 
either an API change to add a parameter, or doubling the set of modes to 
include whether relative traversal is desired, but also seems like it would be 
easy enough.  I'm not sure that there are that many clients of 
canonicalize_file_mode outside of coreutils.

-- 
Eric Blake