[MacPerl] More on the lack of path handling routines

[Scott_Ananian@sil.org]

S>Scott_Ananian@sil.org writes:
S> What's the best (ie most portable) way to construct path names on an
S> arbitrary system?

>>There should be, but aren't, subroutines, in somewhere you can count on
>>being there for any standard Perl installation, that do exactly that.
>>Say in File::Path routines such that $path =
>>File::Path::relpath(@names) gives a relative path and $path =
>>abspath(@names) that gives an absolute path. There should be similar
>>routines to do the reverse, and probably *path should be able to deal
>>with path fragments in @names as well.  Any of us that have done cross
>>platform work have probably already written such stuff. Almost all of
>>the remaining portability problems in any package I've looked at could
>>be dealt with such routines.

That's exactly the point.  It's not that I don't mind writing my own routines;
it's that I'd prefer using 'standard' routines that would be guaranteed to be
present on each new port of perl.  I've got access to MacOS and Win95; I'm sure
I can write routine that will work there -- but what if someone is using a perl
port to OS/2 or VMS and Unix?  My custom written routines would break, but (in
an ideal world) the routines provided with the standard distribution would still
work.

 
S> What is needed:
S> 1) Given a file and a path, create a fully specified filename (combine them)
S>     This obviously will probably involve adding the system specific directory
S> separator; colon on the mac, backslash on Win, forward slash on unix.

>>That's easy with join.  $fullpath = join(":",$path,$file); change the
>> character as needed.  Would be nice if the character itself was in Config.pm.

Well, two problems.  One, as you mentioned, the correct character to use isn't
specified anywhere is 'Standard' Perl (though it's been suggested I import the
whole CGI library to get the separation character). More importantly, I'm not
guaranteed that the join($SEP_CHAR, $path, $file) will work if, say, path is
relative or null -- or if file already has a relative path.

Example: Say I do 'pwd' to get the current working directory; and I've got a
relative filename that, perhaps, the user entered. I want to find the absolute
pathname. On a Mac the input data might look like:

working directory                         relative path
------------------                        --------------
Volume:Directory:Directory:         and  :SubDirectory:File  
                                or maybe ::SubDirectory:File
or perhaps they enter an absolute path,   Vol:Dir:File

on unix, this might be:
/usr/directory/                and  Directory/File
                           or maybe ../Directory/File
                           or even  /u/username/file
         or (perish the thought!)   ~username/file

No simple concatenation will work here, and stripping all leading path
separators and then concatenating will break as well.  Of course, it's very easy
to see what to do in *one given system*; but there isn't a general simple rule
(such as "use join($SEP_CHAR, $path, $file)" that will work in all cases -- or
even most cases. 

Why this bothers me is that the other components of our system are written in
Java and JavaScript -- *completely* architecture neutral.  (OK, well, mostly). 
In other words, I can almost guarantee that the software will run without change
on any of the 16+ platforms currently supporting a Java VM, but the Perl side
will almost certainly break once you leave MacOS or Windoze.

Compounding the problem, Perl refuses the accept the "standard" line-ending
convention of (in regexp format) "\012|\015\012?" (or, a "Linefeed or a Carraige
Return with an optional Linefeed following"), and instead refuses to execute
scripts which have 'incorrect' line endings.  Grumble.

Okay, enough grousing for now.  For this present project, it looks like we'll be
able to make do with determining system type by examining @INC closely, and
define a path separator based on that.  But I was hoping to find a more
portable/universal solution.
  --Scott