Re: [MacPerl] Using UNIX style filenames with MacPerl

[Gerald Young <yog@adis.at>]

On 1998-05-14 01:33, Vicki Brown <vlb@cfcl.com> contributed:

>At 15:26 -0700 98/05/13, Matthew Langford wrote:
>>
>>If one has set the "I want to use Unix-style pathnames" switch, internally
>>convert Mac folders with embedded /'s to :'s,
>
>Unfortunately, it's not that simple.  Unix has a concept of root 
>directory; Mac
>OS does not.  Mac OS volumes are each rooted in the respective volume. You
>could strip the volume name when converting to Unix-style, but converting 
>back?

Most scripts visited either use full pathnames or rooted pathnames to 
some script relevant "root" directory. And the Macintosh also has all its 
volumes "root"-ed. The only problem is to distinguish the different cases 
when seeing a filename and considering the MacOS concept of FSSpec, 
essentially being a volume reference, a directory reference and a 
pathname string.

Thus using references for volume (disc) and directory the MacOS 
filesystem cleverly ovoids problems (and allows using) of identically 
named discs, which is something the "user" (not being a computer 
specialist) likes for sure.

Volume Reference and Directory Reference can easily be translated to 
point to some staring point in the filesystem; and then the pathname 
string starts there and moves at will. Normally the pathname spec will 
only contain a filename (that is the filename part of a pathname - the 
name of a document, regardless of its folder).

"document" translates to "./document" or just "document" using the 
current working directory (the "starting point").

When the pathname strig contains a ":", then it is either a relative or 
an absolute pathname, that is it modifies the directory location and 
specifies the document name.

":document" is identical to "document" (as above) and translates to 
"./document" and refers to a document in the current working directory.

"::document" is identical to "../document" and specifies an object one 
level higher in the directory tree. There is a special case if the 
current working directory is already the top level directory of a device, 
since then "::" is effectively ignored; you cannot specify a device (more 
on this later).

":::document" is identical to "../../document", same as above, only two 
levels up. Stciks silently on the top level of a volume directory tree.

You can use more "::" sequnces to move more levels up, however due to the 
limit in the maximum string length only 255-1(leading ":" for 
"relative")-1(minimum filename length)=253 levels are possible. In 
practice there is a limit of (255-3)/2=126 directory levels, since the 
Finder almost always (and most software anyway) expands filespecs to a 
complete absolute pathname.

More practical limits may lurk elsewhere.

":folder:document" translates to "./folder/document" or "folder/document" 
and refers to a (sub-)folder in the current working directory and a 
document located there.

Here the principal difference in pathnames is obvious:

In UNIX everything is either absolute, rooted at "/" when the string 
starts with a slash, and only when it start with a slash "/".

Anything else starts in the current working directory, either using the 
"./" notation or not.

In MacOS is relative when it starts with a ":", or does not contain any 
":".

Should be easy to detect.

However, consider this "A/../B/doc" could be parsed syntactially 
resulting in "B/doc"; but can also be parsed with respect to the actual 
working directory and fail to parse if there is no "A" directory. Under 
UNIX however, the current working directory is always defined. The same 
problem could be constructed at any level below, as in "A/B/../C/doc".

The exact method of parsing should be well documented.

As to the rooted problem: Any pathname on MacOS containing a ":" and not 
starting with a ":" is, as said before, an absolute pathname, and thus 
rooted at the volume tree.

"Floppy:Folder:Document" then translates to "/Floppy/Folder/Document" as 
seen under Rhapsody. Since the filesystem can be "mounted" anywhere in 
the tree under unix, it is only a special case that volumes start at the 
topmost level, aka root, namely "/".

Using Aliases one could "mount" any volume anywhere in the (MacOS) tree, 
it then  would appear twice (as /VolumeA and /VolumeB/folder/VolumeA).

MacOS, however, can have multiple identical named volumes; these are 
indistinguishable using pathnames. A problem well knwon to MPW users :)

(Look at the FTP server in Anarchie 2.x; all and only 
AppleShare-published volumes appear under "/" for FTP clients - nice, but 
not applicable with MacPerl ? )

Another UNIX special is the tilda "~" specification of a user's login 
directory; say "~yog" and you start at the login/default directory of the 
account/user "yog" . Neat.

(What is "~/document"? If undefined under UNIX maybe this is a way to 
implement ambiguous volume name resolution in MacPerl -> ~/Harddisk -> 
~/Harddisk/19980502121340/../ using the creation date as "hidden" 
pathname part. MacOS uses the creation date of a volume to resolve 
ambiguity then). Maybe "~/" is the current user id's login folder?

The "~" must be treated specially, since under UNIX the current directory 
is then "well defined", but under MacOS the current directory is more or 
less undefined (most likely the MacPerl application directory - same 
problem is present with MacPerl doplets and ARGV parameters - discussed 
elsewhere I presume).

Maybe the "~" should be resolved to the "General Controls" CP "Documents" 
folder in absence of something useful in MacOS ('til Mac OS X ;-) maybe 
). The Documents folder should be used, if "~/" (see above) specifies the 
current users login direcory.

>Also .. is functionally equivalent to :: but ../.. is equivalent to :::

Jep.

>If it were a simple matter of s#/#:# it would probably be running already...

Jep.
Or interoperability was not a prime issue, the main problem stems from 
hardcoded filenames anyway.

>>Or (less desireable) don't support it at all--in other words,
>>barf/carp/die if a Mac folder containing "/" or leading dots is found.
>
>Oh, please, no.  I just tried out a TeX formatter that can't deal with with /
>anywhere in the path from volume to file.  The file (which I chose with a
>standard file open dialog!) was on the desktop.  Meaning in the Desktop 
>Folder.
>Of a volume whose name happens to be /system.  I name my boot volume with a
>leading /; it sorts to the top in open/save dialogs.

Clever, but agreed. No mixing of meta information here.

I agree that sometimes it is just nicer to have "/" included in file and 
foldernames; maybe UNIX's perl scripts could be run this portable under 
MacPerl. But then parsing filenames would require accessing the 
filesystem to determine the existence of matching folders/files.

I am not sure I (or other) would like seeing trailing "/" in 
file/foldernames then, but maybe.

>I've run across several installers and other programs recently which can't
>handle that and convert the volume name to ystem!
>
>No.  I'm backing Matthias on this one; it's like the \n translation 
>discussion;
>if we can't find an elegant way to do it right, we'd best not do it at all;
>that, at least, as predictable results.

Hmm; and Millions of MacPerl users have to hand-edit UNIX CPAN scripts. 
Clever?

-- Gerald

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch