Re: [PATCH 0/6] realpath cleanups

[Eric Blake]

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).

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature