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

Previous Next

Full log

Message #46 received at 10472 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Mike Frysinger <vapier <at> gentoo.org>, 10472 <at> debbugs.gnu.org
Subject: Re: bug#10472: `realpath --relative-to=<path> /` outputs inconsistent
	trailing slash
Date: Mon, 30 Jan 2012 23:53:08 +0000

On 01/30/2012 10:22 PM, Eric Blake wrote:
> On 01/30/2012 03:01 PM, Pádraig Brady wrote:
>>> $ 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'.
> 
> Correct.
> 
>> To match up with that, I think it makes sense to only do this on systems
>> where a double slash is significant.
> 
> I'm tending to agree - readlink, dirname, and realpath should all behave
> consistently within a single compilation of coreutils.
> 
>>
>> 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.
> 
> Correct.
> 
> Another bug still in the latest coreutils.git, but only on platforms
> with distinct //:
> 
> $ src/realpath / // ///
> /
> //
> //
> 
> Oops, that last line should be /.  This bug is shared by readlink:
> 
> $ src/readlink -m ///
> //

The above will require a gnulib fix

>> gnulib says // matters for Apollo DomainOS (too old to port to),
>> Cygwin, and z/OS.
> 
> And I tested on Cygwin (if it wasn't obvious :)
> 
> I can try to develop patches as part of porting coreutils 8.15 to cygwin

I'll take you up on that, thanks!

> (cygwin already has a realpath(1), but it is severely limited in that it
> only takes one file name and no command line options on what to do with
> that name; I'm pretty sure that the coreutils realpath is upwards
> compatible with the existing cygwin realpath:
> http://cygwin.com/ml/cygwin-apps/2012-01/msg00080.html).

I had a look at the source, and it's just a simple wrapper around realpath(),
that only accepts a single path. So coreutils realpath should be a drop in replacement.
(wow it's hard to navigate cygwin stuff. It took me 3 mins to find the latest source).

cheers,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.