Re: [Plib-devel] Mac Updates/Patches (Tux too!)

[Curtis L. O. <cu...@me...>]

Steve Baker writes:
> > The mac-to-unix conversion would just be separator replacement though. Take
> > the leading ':' and convert to '../' and then for the rest replace ':' with
> > '/'
> 
> What about things like '~' in UNIX (it means "my home directory") and '~fred'
> (meaning "fred's home directory) ?

I belive '~' expansion is called "globbing" in unix and is typically
done at the shell level (i.e. is expanded by the shell.)  The unix
libc doesn't have any "glob" functionality built in and programs that
"glob" usually fake it and quite often don't do nearly as nice of a
job as the shell.  Try writing a simple C program that opens
"~sjbaker/junk" (the string being hardcoded and not passed in from the
shell) and see what happens.

> Perhaps it would be smart to define a class that expresses a filename in
> an OS-neutral manner (eg as an array of strings - so no separators are
> involved - and the only ".." operators are at the top - and stuff like the
> Windoze 'C:' drive name and the Linux/UNIX "~" are removed).
> 
> Then that class could have 'fromUNIX', 'fromMacOS', 'fromWin" and so on to
> convert existing file names into the class - and then operations like
> 'fopen' that internally convert to whatever native format the OS needs
> before doing their work.
>  
> The application could then be written in whatever native style the author
> prefers - and the class would convert to whatever target OS is needed.
> 
> That way, you only have to write a 'fromXXX' and 'toXXX' convertor for
> each OS in order to have every possibility covered.  Otherwise, we'll
> be forever writing 'BeOS_to_Amiga', 'CP/M_to_legOS' and such like.

I will lobby for KISS here.  If you make something that is too all
encompassing and can handle just about every possible situation the
most deviant OS designer could come up with there is a good chance you
will end up with a library that is complex and unwieldy and is a
hassle to use ... in which case people often won't.

I like the flight gear FGPath class myself.  It can't handle every
case you could dream up, but it is pretty simple and easy to use (and
easy to convert hardcoded paths to use FGPath.)  With a little thought
on the part of the app writer to avoid degenerate situations, the
FGPath class can be made to work very well ...

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org