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

[Steve B. <sjb...@ai...>]

"Curtis L. Olson" wrote:

> > 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.

Doh!  Of course!  I knew that...  :-)

> > 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.

Well, I don't think this would be hard to use:

   ulFilename fname ( "/home/steve/tux/models/tux.ac", UL_UNIX ) ;

...or...

   ulFilename fname ( "C:\HOME\STEVE\TUX\MODELS\TUX.AC", UL_WINDOZE ) ;

...or...

   ulFilename fname ( "home:steve:tux:models:tux.ac", UL_MACOS ) ;

...(any of those would work on any of those operating systems)...and then:

   FILE *fd = fname -> fopen ( "r" ) ;

...and that's *it*.

We could go on to add frills like:

   fname . getFileName () ;

...which returns "tux.ac"...or whatever is appropriate for the OS type
the ulFileName was created in.

Internally, converting to and out of a standard internal form wouldn't be that
hard.

> 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 ...

I think that with FGFS, you have a slightly easier task.  You have only
one set of users on one (admittedly large) project.  For something like
PLIB, where we don't know where it'll ultimately end up, I think we have
to be more robust.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net