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.