[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 22:04:53 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 |
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
> 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"
}
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.
cheers,
Pádraig.
- Re: [PATCH 5/6] doc: clarify current realpath --relative-base behavior, (continued)
- [PATCH 2/6] realpath: fix problems with root handling, Eric Blake, 2012/03/14
- [PATCH 6/6] realpath: let --relative-base work even as child of --relative-to, Eric Blake, 2012/03/14
- [PATCH 1/6] test: expose recent gnulib canonicalize bug, Eric Blake, 2012/03/14
- [PATCH 4/6] realpath: let --relative-to default to --relative-base, Eric Blake, 2012/03/14
- [PATCH 3/6] tests: cover more realpath scenarios, Eric Blake, 2012/03/14
- Re: [PATCH 0/6] realpath cleanups,
Pádraig Brady <=