Re: readlink(1) behavior

[Jim Meyering]

Dmitry V. Levin wrote:
> On Thu, Sep 10, 2009 at 07:29:35PM +0200, Jim Meyering wrote:
>> 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.
>
> Yes, but there is a corner case:
> I think that 'readlink -fv broken_symlink/' behavior should not change.

Building coreutils to use the very latest from gnulib,
this has indeed just changed.  Not deliberately, it appears.

Assuming ln -s /nowhere dangling-symlink,
New behavior:

    $ ./readlink -fv dangling-symlink/
    /nowhere

Previous:

    $ readlink -fv dangling-symlink/
    readlink: dangling-symlink/: No such file or directory
    [Exit 1]


>> > 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.
>
> A new option for this new mode looks more appropriate,
> I'd like to see old -m behavior unchanged for backwards compatibility.

Right.  IMHO there is no justification to change existing behavior.