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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature