Re: Path separator in NSBrowser on MinGW

[Richard Frith-Macdonald]

On Sunday, April 28, 2002, at 01:09 PM, Alexander Malmberg wrote:

> > > [snip]
> > > > There may be another way to achieve the same OS independence. We 
> > > > could
> > > > define that all file and path names inside of GNUstep libraries and
> > > > applications should be in the UNIX style and only convert the names 
> > > > to
> > > > the OS specific form, when we actually need to access a file.
> > >
> > > Isn't this how it's supposed to work? I always thought so, and the 
> > > docs
> > > seem to imply it, eg.:
> >
> > Yes ... but looking at the NSFileManager method, it seems it was never
> > ported to windoze, though the counterpart
> > fileSystemRepresentationWithPath:
> > method was!
>
> But you agree that this is an NSFileManager issue, and not an NSBrowser
> or application issue? I do _not_ want to bother with portable path
> handling in my apps.

Well, not entirely.  I think that 
stringWithFileSystemRepresentation:length:
*should* probably map windows style paths to unix style, but that's not 
the
whole issue.

I think GNUstep-base was coded to handle *both* unix and windoze style 
paths
internally, and the path manipulation routines try to 'do the right 
thing'
for the platform they are running on.  This is why stuff mostly works 
fine
even though -stringWithFileSystemRepresentation:length: does not map 
between
windoze and unix style paths.

However, this means that user code which expects to find a particular 
character
used as the path separator will not be portable (though code which just 
uses
the standard string methods for manipulating paths should be ok).

I think Freds suggestion is (like your idea) that we should *only* ever 
use
unix style paths internally.

This requires three changes -
1. Implement -stringWithFileSystemRepresentation:length: for windoze
(I already have code for this)
2. Remove all the windoze specific path handling code from the string 
methods
3. Make sure that -stringWithFileSystemRepresentation:length: is used 
wherever
paths are entered into the system.

That amounts to quite a bit of work ... I'd like to be sure it's the 
correct
thing to do before going ahead.

Perhaps the correct action instead is to say that all path handling code 
should
use the NSString path handling methods, and not assume anything about 
what the
path separator is?  I think this existing state is probably wrong.