[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: readlink(1) behavior
From: |
Dmitry V. Levin |
Subject: |
Re: readlink(1) behavior |
Date: |
Fri, 18 Sep 2009 14:16:00 +0400 |
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.
> > 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.
--
ldv
pgp_KnbWniQLs.pgp
Description: PGP signature
- 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 <=
- Re: readlink(1) behavior, Jim Meyering, 2009/09/18
- Re: readlink(1) behavior, Eric Blake, 2009/09/18
- Re: readlink(1) behavior, Jim Meyering, 2009/09/18
- Re: readlink(1) behavior, Jim Meyering, 2009/09/19
- Re: readlink(1) behavior, Dmitry V. Levin, 2009/09/19
- Re: readlink(1) behavior, Eric Blake, 2009/09/23
- Re: readlink(1) behavior, Jim Meyering, 2009/09/23