gnustep-dev
[Top][All Lists]
Advanced

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

Re: Installation on windows (fwd)


From: David Ayers
Subject: Re: Installation on windows (fwd)
Date: Thu, 17 Mar 2005 10:21:55 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217

Richard Frith-Macdonald wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005-03-16 19:38:44 +0000 Jeremy Bettis <address@hidden> wrote:

However, -lastPathComponent would return 'test.txt' for the first string and
'Temp\test.txt' for the second string as these are assumed to be posix
paths.
Perhaps OPENSTEP did the same thing?


I can tell you from experience what OPENSTEP did. Methods like writeToFile: didn't touch the filename at all. Remember windows doesn't care which way the slashes go, so fopen("c:\\temp\\text.txt", "r") is EXACTLY the same as fopen("c:/temp/text.txt", "r") is EXACTLY the same as fopen("c:\\temp/text.txt", "r"). And lastPathComponent would return the part of the string after either / or \.

So [@"c:/temp\\text.txt" lastPathComponent] returned @"text.txt" and [@"c:\\temp/text.txt" lastPathComponent] returned @"text.txt" also.

And I wish gnustep worked the same way.


Oops ... I got it wrong ... GNUstep *will* do that on mingw. It always uses
'/' for building paths,
but will accept '\\' when parsing them on mingw.
I'm not at all sure that is *good* behavior though ... why do you 'wish
gnustep worked the same way' ?
Given that it apparently does work the same way,  I guess your desire is
theoretical rather than practical as you can't have had any problems with it
not doing that.

Hmm, actually OPENSTEP for NT is based on some cygwin variant (at least that's what the tool chain indicates), so this behavior actually is not really surprising.

I'm not suggesting that we should forcibly break this, but I do wish the paths provided by the GNUstep library are always in the POSIX format (I'm not aware of the current behavior) making it the "preferred" format.

OTOH, I can understand that for an stand alone application to be "integrated naturally" into the windows environment, where users are used to seeing and typing paths with \, this may be very annoying. So possibly the "preferred format" should in some way be customizable.

The add-on I'm hinting at is a standardized utility to deal with paths coming from other sources like user input, environment variables or paths coming via DO from other systems, so they can be easily converted to POSIX format when doing extensive path manipulations. The point is to be able to reliably compare (and sort) paths.

Cheers,
David





reply via email to

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