plib-devel

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

[Norman V. <nh...@ca...>]

FYI --- Generalized Mac Path conversions are not really as kissable
as they might at first appear :-(

Following sniped from dis...@py...

>> > Unfortunately, it seems like sometimes the trailing ":" is required.
To
>> > explain why, I need to explain a little bit more about mac pathnames.
On
>> > the mac, a path starting with a colon is relative, while one which
doesn't
>> > start with a colon is absolute (ie. the reverse of the posix
convention),
>> > _unless_ it's just a single name (ie. no colons whatsoever) in which
case
>> > it's relative.  The end result of this is that "Macintosh HD" refers to
a
>> > file in the local directory called "Macintosh HD" (as does ":Macintosh
>> > HD"), while "Macintosh HD:" refers to the root directory of the hard
disk
>> > "Macintosh HD".
>> >
>> > However, "Macintosh HD:Applications:" and "Macintosh HD:Applications"
are
>> > the same thing as each other. Similarly ":Macintosh HD:Applications:"
and
>> > ":Macintosh HD:Applications" are the same as each other.
>>
>> Ooh, tricky!  Now I can see why Mac OS doesn't have a command-line
>> interface: if users can't understand the difference between "/foo" and
>> "foo", how on earth will they understand that "foo" == ":foo" != "foo:",
>> while "foo:bar" == ":foo:bar" (but "foo:bar" == "foo:bar:" and
>> ":foo:bar" == ":foo:bar:").  Aieee!  Doesn't quite rival VMS for
>> complexity, but it's getting there.
>
>Actually it's
>
>":foo" == "foo" != "foo:"
>
>but
>
>":foo:bar" != "foo:bar" == "foo:bar:"
>
>> > There's a similar problem with ":", "::", etc.  Removing a trailing ":"
in
>> > these cases directly affects the meaning.
>> [...]

Norman

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

[Darrell W. <dwa...@pu...>]

For relative paths, I am pretty sure folders end in ':' and files do not.

For PLIB, I think we will make all our paths relative. Therefore *all* paths
will have ':' at the beginning. Since we are not opening directories,
I don't think we have to worry about trailing ':'

so UNIX ->  "foo.bar" -> MAC ":foo.bar"

or "../foo.bar" -> "::foo.bar"

UNIX -> /usr/local/share -> MAC ":usr:local:share"

Hopefully that last one doesn't come up too often ;-) We just have to remind
developers to always use relative pathnames (even on UNIX/WINDOWS) and we
should have no problems.

This reminds me, when needing full paths, like for home directory or
whatnot, I think the usual is to call  getenv ("HOME"). But MacOS has no
concept of $HOME. In fact, the CodeWarrior C Library function getenv() on
MacOS always returns NULL.

I think we should add getHome to our file class.
The MacOS version can return the path to the preferences folder (global
place where 99% of Mac apps store settings, hence why mine has 500 some-odd
files in it ;-) ).


> From: "Norman Vine" <nh...@ca...>
> Reply-To: pli...@li...
> Date: Thu, 3 Aug 2000 23:58:00 -0400
> To: <pli...@li...>
> Subject: Re: [Plib-devel] Mac Updates/Patches (Tux too!)
> 
> FYI --- Generalized Mac Path conversions are not really as kissable
> as they might at first appear :-(
> 
> Following sniped from dis...@py...
> 
>>>> Unfortunately, it seems like sometimes the trailing ":" is required.
> To
>>>> explain why, I need to explain a little bit more about mac pathnames.
> On
>>>> the mac, a path starting with a colon is relative, while one which
> doesn't
>>>> start with a colon is absolute (ie. the reverse of the posix
> convention),
>>>> _unless_ it's just a single name (ie. no colons whatsoever) in which
> case
>>>> it's relative.  The end result of this is that "Macintosh HD" refers to
> a
>>>> file in the local directory called "Macintosh HD" (as does ":Macintosh
>>>> HD"), while "Macintosh HD:" refers to the root directory of the hard
> disk
>>>> "Macintosh HD".
>>>> 
>>>> However, "Macintosh HD:Applications:" and "Macintosh HD:Applications"
> are
>>>> the same thing as each other. Similarly ":Macintosh HD:Applications:"
> and
>>>> ":Macintosh HD:Applications" are the same as each other.
>>> 
>>> Ooh, tricky!  Now I can see why Mac OS doesn't have a command-line
>>> interface: if users can't understand the difference between "/foo" and
>>> "foo", how on earth will they understand that "foo" == ":foo" != "foo:",
>>> while "foo:bar" == ":foo:bar" (but "foo:bar" == "foo:bar:" and
>>> ":foo:bar" == ":foo:bar:").  Aieee!  Doesn't quite rival VMS for
>>> complexity, but it's getting there.
>> 
>> Actually it's
>> 
>> ":foo" == "foo" != "foo:"
>> 
>> but
>> 
>> ":foo:bar" != "foo:bar" == "foo:bar:"
>> 
>>>> There's a similar problem with ":", "::", etc.  Removing a trailing ":"
> in
>>>> these cases directly affects the meaning.
>>> [...]
> 
> Norman
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

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

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

Darrell Walisser wrote:
> 
> For relative paths, I am pretty sure folders end in ':' and files do not.
> 
> For PLIB, I think we will make all our paths relative. Therefore *all* paths
> will have ':' at the beginning. Since we are not opening directories,
> I don't think we have to worry about trailing ':'
> 
> so UNIX ->  "foo.bar" -> MAC ":foo.bar"
> 
> or "../foo.bar" -> "::foo.bar"
> 
> UNIX -> /usr/local/share -> MAC ":usr:local:share"
> 
> Hopefully that last one doesn't come up too often ;-) We just have to remind
> developers to always use relative pathnames (even on UNIX/WINDOWS) and we
> should have no problems.

Iguess that makes sense because:

1) It avoids the drive name issue under Windoze ('C:', etc)

2) It's unlikely that an absolute path under one OS would even exist
   under another.

> This reminds me, when needing full paths, like for home directory or
> whatnot, I think the usual is to call  getenv ("HOME"). But MacOS has no
> concept of $HOME. In fact, the CodeWarrior C Library function getenv() on
> MacOS always returns NULL.
> 
> I think we should add getHome to our file class.
> The MacOS version can return the path to the preferences folder (global
> place where 99% of Mac apps store settings, hence why mine has 500 some-odd
> files in it ;-) ).

Yes - I think that's a good plan.
 
We'd also need a way to get a path from a 'shell variable' - or whatever
other preferences mechanism you have - that would let (for example) a game
find all it's data files.

Since the preference mechanisms vary - and the path name you get from
that mechanism will be in LOCAL form - not in the form that the
game writer was necessarily expecting - that will have to be handled
within the library.

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

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

[Norman V. <nh...@ca...>]

Steve Baker writes:
>
>Darrell Walisser wrote:
>>  
>> Hopefully that last one doesn't come up too often ;-) We 
>just have to remind
>> developers to always use relative pathnames (even on 
>UNIX/WINDOWS) and we
>> should have no problems.
>
>Iguess that makes sense because:
>
>1) It avoids the drive name issue under Windoze ('C:', etc)

AFAIK there us no why to refer to a file on another disk with
a relative path in windows.

Therefore we need to account for the drivename issue under
Windows but that is an easy on to do.

As Curt pointed out we can just borrow the Path Class from
SimGear.  I was just trying to point out that it might need a 
little tuning yet for some Mac path constructs.
 
Norman