On 03/14/2012 09:53 AM, Eric Blake wrote: > On 03/14/2012 03:12 AM, Pádraig Brady wrote: >> On 03/14/2012 04:07 AM, Eric Blake wrote: >>> On 03/13/2012 09:15 PM, Eric Blake wrote: >>>>> Also doesn't path_prefix() need the same adjustment, >>>>> so as to verify --relative-base in the same way? >>>> >>>> Yes, it looks like it. >>> >>> In fact, I found another bug, this time present also on Linux: >>> >>> $ realpath --relative-base=/ --relative-to=/ / >>> / >> >> This may be a local issue? >> $ src/realpath --relative-base=/ --relative-to=/ / >> . > > Looks like I was testing after some of my modifications to realpath.c; > I'm rebasing my tree to add the test before any of my realpath.c > changes, so that I can then be avoiding regressions. But it still > doesn't explain: > > $ src/realpath --relative-base=/ --relative-to=/ / /usr > . > /usr
Agreed. --relative-base=/ should essentially be a noop > where I would expect 'usr', not '/usr', since /usr is indeed a child of /. > >>> $ realpath --relative-base=/usr/local --relative-to=/usr \ >>> /usr /usr/local/lib >>> /usr >>> /usr/local/lib >>> >>> when it should really output '/usr' (absolute, since it is not a child >>> of /usr/local) and 'local/lib' (which is a file below /usr/local, and an >>> output name relative to /usr). >> >> Well that was by design. I.E. --relative-base is a guard, >> which if either --relative-to or the specified paths go higher, >> an absolute name will be output. > > The documentation wasn't very clear on that point. Either we need to > fix the documentation, or consider whether to make 'realpath' fail if > --relative-base is not a prefix of --relative-to, or even add another > option that allows the behavior I was expecting of making the two > orthogonal (that is, where it really is an independent filter - if the > path being canonicalized is a child of --relative-base, then output it > relative to --relative-to; otherwise output absolute). > > Also, would it make sense to have --relative-base without --relative-to > imply a --relative-to of the same directory? That is, > > realpath --relative-base=/usr /usr I considered that, and now I'm not sure why I didn't do it. Having both relative-to and relative-base being the same, is the common use case for --relative-base. cheers, Pádraig.
