bug#10472: [PATCH] realpath: fix problems with // handling

[Pádraig Brady]

On 03/14/2012 09:53 AM, Eric Blake wrote:
> On 03/14/2012 03:12 AM, Pádraig Brady wrote:
>> On 03/14/2012 04:07 AM, Eric Blake wrote:
>>> On 03/13/2012 09:15 PM, Eric Blake wrote:
>>>>> Also doesn't path_prefix() need the same adjustment,
>>>>> so as to verify --relative-base in the same way?
>>>>
>>>> Yes, it looks like it.
>>>
>>> In fact, I found another bug, this time present also on Linux:
>>>
>>> $ realpath --relative-base=/ --relative-to=/ /
>>> /
>>
>> This may be a local issue?
>> $ src/realpath --relative-base=/ --relative-to=/ /
>> .
> 
> Looks like I was testing after some of my modifications to realpath.c;
> I'm rebasing my tree to add the test before any of my realpath.c
> changes, so that I can then be avoiding regressions.  But it still
> doesn't explain:
> 
> $ src/realpath --relative-base=/ --relative-to=/ / /usr
> .
> /usr

Agreed. --relative-base=/ should essentially be a noop

> where I would expect 'usr', not '/usr', since /usr is indeed a child of /.
> 
>>> $ realpath --relative-base=/usr/local --relative-to=/usr \
>>>     /usr /usr/local/lib
>>> /usr
>>> /usr/local/lib
>>>
>>> when it should really output '/usr' (absolute, since it is not a child
>>> of /usr/local) and 'local/lib' (which is a file below /usr/local, and an
>>> output name relative to /usr).
>>
>> Well that was by design. I.E. --relative-base is a guard,
>> which if either --relative-to or the specified paths go higher,
>> an absolute name will be output.
> 
> The documentation wasn't very clear on that point.  Either we need to
> fix the documentation, or consider whether to make 'realpath' fail if
> --relative-base is not a prefix of --relative-to, or even add another
> option that allows the behavior I was expecting of making the two
> orthogonal (that is, where it really is an independent filter - if the
> path being canonicalized is a child of --relative-base, then output it
> relative to --relative-to; otherwise output absolute).
> 
> Also, would it make sense to have --relative-base without --relative-to
> imply a --relative-to of the same directory?  That is,
> 
> realpath --relative-base=/usr /usr

I considered that, and now I'm not sure why I didn't do it.
Having both relative-to and relative-base being the same,
is the common use case for --relative-base.

cheers,
Pádraig.