bug#10472: `realpath --relative-to=<path> /` outputs inconsistent trailing slash

[Pádraig Brady]

On 01/30/2012 09:10 PM, Eric Blake wrote:
> On 01/10/2012 01:15 PM, Mike Frysinger wrote:
>> however, if the last argument is just the root path:
>>      realpath --relative-to=/usr /
>>      realpath --relative-to=/usr/ /
>> we end up with a trailing slash:
>>      ../
>>
>> for consistency, i don't think that should be the case
>>
>> (reported by Ulrich Müller via https://bugs.gentoo.org/398339)
> 
> Another bug, on a system where // is distinct from /:
> 
> $ realpath --relative-to=/ //machine / // /bin
> machine
> .
> .
> bin
> $ realpath --relative-to=// //machine / // /bin
> machine
> .
> .
> bin
> 
> when it should really be:
> 
> $ realpath --relative-to=/ //machine / // /bin
> //machine
> .
> //
> bin
> $ realpath --relative-to=// //machine / // /bin
> machine
> /
> .
> /bin
> 
> We need to make realpath robust to correct leading // handling; I don't
> know if we should follow the lead of 'dirname' in only doing it on
> machines where // is special, or if it is easier to make it honor POSIX
> by special-casing // everywhere even on machines where / and // are
> identical.

So on such a machine, I guess `readlink -m //machine/` outputs '//machine'.
To match up with that, I think it makes sense to only do this on systems
where a double slash is significant.

BTW, this is how I'm interpreting this example:

> $ realpath --relative-to=// //machine / // /bin
> machine
> /
> .
> /bin

I'm taking --relative-to=// to mean relative to "the network".
Hence relative output will be machines on the network,
while absolute are local paths.

gnulib says // matters for Apollo DomainOS (too old to port to),
Cygwin, and z/OS.

cheers,
Pádraig.