coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/6] realpath cleanups


From: Pádraig Brady
Subject: Re: [PATCH 0/6] realpath cleanups
Date: Wed, 14 Mar 2012 23:25:52 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

On 03/14/2012 10:15 PM, Eric Blake wrote:
> On 03/14/2012 04:04 PM, Pádraig Brady wrote:
>> On 03/14/2012 08:38 PM, Eric Blake wrote:
>>> As promised, here's my cleaned up series for http://debbug.gnu.org/10472
>>
>> This is very thorough.
>> I can't find any logic issues at all.
>>
>>> I'm not sure whether to squash 2 and 3 into one patch.
>>
>> separate is fine
> 
> Jim, any problems before I push 1-4? Let's settle on a decision on 6
> before I push any more than that.
> 
>>
>>> I'm not sure whether we want patch 6/6, so I documented the current
>>> behavior in 5/6; if we want both, then it's best to squash the two
>>> together (that is, effectively get rid of 5/6).
>>
>> I'm still pondering this.
>> I was thinking that --relative-base was a point across
>> which you didn't want any relativity happening.
>>
>> point1_rel() {
>>   realpath --relative-base=/mnt/point1/ --relative-to=. "$1"
>> }
> 
> Based on your function name, I think you meant to return a name relative
> to point1, not relative to the current location:
> 
> point1_rel() {
>   realpath --relative-base=/mnt/point1/ --relative-to=/mnt/point1 "$1"
> }
> 
> or, thanks to 4/6:
> 
> point1_rel() {
>   realpath --relative-base=/mnt/point1/ "$1"
> }
> 
>>
>> But your argument reproduced in the following paragraph is valid too:
>>
>> Consider: 'realpath --relative-base=$dir --relative-to=. $file'
>> It seems reasonable to get a relative name to $file if file is under
>> $dir, without regards to where '.' lives, but prior to this patch,
>> if '.' is a parent of $dir, the output was absolute.
>>
>> I err'd on the side of compatibility with existing tools.
>>
>> I'll think some more about it.
> 
> No problem - there's a difference between bug fixes (1-3) and feature
> changes (4-6).

Having thought a bit more about it, wrt to patch 6, I
think it's marginally better to drop it and keep the
existing behaviour, for compat reasons.

I'm very happy for 1-5 to go in though.

Thanks again for this excellent series.

Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]