[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: readlink(1) behavior
Re: readlink(1) behavior
Fri, 18 Sep 2009 12:47:31 +0200
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,
$ ./readlink -fv dangling-symlink/
$ readlink -fv dangling-symlink/
readlink: dangling-symlink/: No such file or directory
>> > 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.
- readlink(1) behavior, Eric Blake, 2009/09/10
- Re: readlink(1) behavior, Jim Meyering, 2009/09/10
- Re: readlink(1) behavior, Eric Blake, 2009/09/10
- Re: readlink(1) behavior, Eric Blake, 2009/09/12
- Re: readlink(1) behavior, Dmitry V. Levin, 2009/09/18
- Re: readlink(1) behavior, Eric Blake, 2009/09/23
- Re: readlink(1) behavior, Jim Meyering, 2009/09/23