Re: [MacPerl] Using UNIX style filenames with MacPerl

[Gerald Young <yog@adis.at>]

On 1998-05-14 00:26, Matthew Langford <langfml [at] eng [dot] auburn [dot] edu> 
contributed:

>On Wed, 13 May 1998, Paul J. Schinder wrote:
>
>> } Would it be possible to "teach" MacPerl to directly support the
>> } UNIX-style file and pathnames when accessing files.
>> 
>> No.  It would be a terrible idea.  Suppose I had a folder named "5/13/98",
>> or one named "..".  What would you want MacPerl to do in this case?
>
>How many people have folders named ".." or "."?

Any filename starting with a dot "." is regarded special even on the Mac, 
as in the (good) old days devicenames were distinguished from filenames 
via the leading period. That constraint was relaxed later on (most likely 
a problem with the opening of desk accessories, which were handled like 
device drivers then).

Although it is possible to make a file name start with a period, it is 
(still) strongly discouraged and most file system reair utilities (eg 
Norton) will complain about this.

So I see no problem with "." or ".." for the 99.99% of Mac users.

Another case is the unix convention of naming "normal invisible" files 
with a leading period, as in ".profile"; some perl scripts I encountered, 
and most of these are in the class internet/web/http/web etc, were 
keeping bookmarks in dot-files. Hunting and changging these in even a 
moderate perl scripted environment is not funny, and hence my original 
request.

>   If a special case is
>_that_ infrequent, even the most egregious kludge is supportable. 
>Translate it internally to some name like "forbidden_dotdot".  And what if
>someone already has a folder named "forbidden_dotdot"?  Then they've
>voided the MacPerl warranty, and must face the wrath of the gods.

See above; only "." (current directory, ":" on MacOS) and ".." (parent 
directory, "::" in MacOS pathnames) have to be translated, other 
dot-special files only have to be treated carefully to use the 
appropriate "File-" routine (as opposed to File AND Device capapble 
routines (I seem to remember HFSdispatch is all save; there is some 
TechNote regarding these issues, Matthias surely knowns about them).
>
>If one has set the "I want to use Unix-style pathnames" switch, internally
>convert Mac folders with embedded /'s to :'s, or some other suitable
>character (a "plus" sign? an underscore? a dash? an em-dash? an en-dash?
>the choice is left as an exercise for the reader).

Hmm is this conversion (of MacOS pathnames to "internal" MacPerl UNIX-ish 
pathnames) really necessary? all I want to to is to use generic 
UNIX-originated scripts without modifying strange things all over the 
source script files. I would appreciate being told whenever an filename 
used in MacPerl is "insecure" (when it contains slashes or leading 
periods, or ":") to avoid portability problems.

I do not like the UNIX-style filesystems, and for sure do not prefer 
either file system; but I would like to use CPAN scripts...

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

Compatibility warning prefered, but then also length issues (27 dir 
name,31 file name,255 bytes total path name - 255 characters (!) in HFS+).

>After all, if I've told MacPerl I want to use Unix style pathnames, I'm
>not likely to violate Unix conventions in the folders I run it on.  If I'm
>only worried about running it on Macs, I won't throw the
>"wanna-use-Unix-paths" switch.

Exactly. Wanna-use-unix-script.

>  If I want to run it on both, I'll have to
>code up a translator myself--which strikes me as false hubris.  Better to
>have it done once, and widely tested.

Go.

-- Gerald

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