bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pádraig Brady
Subject: bug#10472: `realpath --relative-to=<path> /` outputs inconsistent trailing slash
Date: Mon, 30 Jan 2012 23:53:08 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]