Re: [MacPerl] "Epoch-making difference"--time()

[schinder@pjstoaster.pg.md.us (Paul Schinder)]

bob.dalgleish@sasknet.sk.ca (Bob Dalgleish) writes:
} At 10:08 AM 4/5/96, Paul Schinder wrote:
} >What would be nicer is if Config.pm lost a lot of its Unixcentrism and
} >contained some actually useful stuff for the local configuration.
} Legal filename characters will almost always be a problem that cannot be
} handled by mapping functions -- In any case, it will be required that any
} cross-platform file naming system be restricted in its character set.
} >. . .what character begins a relative path, what
} Characters -- on Unix "./" begins a relative path.

Actually I was thinking of the null string.  ./ is a no-op, and it's
only necessary in rare cases.  What I had in mind was that relative
paths on the Mac always (yes, I know, but let's not confuse the newbies)
begin with ":", while absolute paths in Unix always begin with /, etc.

} >character begins an absolute path, etc., etc.  Maybe even some simple
} >routines that can construct legal paths out of lists, extract the filename
} > from a legal full path, etc.  *That* would be useful for everyone, and
} >would make writing portable Perl much easier.
} 
} Has anyone looked at File::basename.pl lately?  It defines some file name
} parsing routines that have been adapted for Unix, , VMS, MacOS and DOS.

I just looked in /usr/local/lib/perl5 on my Sun, and the 5.002
distribution doesn't have this.  It's in CPAN?  Something like this
should be absolutely standard, and guaranteed to give proper results on
the local machine, with maybe the added ability to let you use it for
cross platform purposes.  What you need is something that you can rely
on being there (hence Config.pm) and that will always do the right thing
for the local machine.

} 
} It provides:
} 
} fileparse("Long:file name:no:can.say") => ("can.say", "Long:file name:no:")
} basename("Long:file name:no:can.say") => "can.say"
} or
} basename("Long:file name:no:can.say", ".say") => "can"
} dirname("Long:file name:no:can.say") => "Long:file name:no:can.say"
} 
} If you want to parse Unix file names on a MacOS host, you can set the OS
} type as well.
} 
} To extend Paul's idea, I think we want to go in several directions:
} 
} 1) Extend Config.pm to identify the dynamic configuration of the host
} operating system.  Currently, $Config{'osvers'} returns '7.5', which is
} true for my machine and Matthias' machine, but not necessarily so for
} anybody elses'.  Since Config.pm is created by the builder, a mechanism
} needs to be designed for this.

That's a reasonable idea, but since it's simply a one-time thing, I
don't think it's unreasonable to suggest to a user that they edit
Config.pm to reflect their own setup.  Before you can do that, though,
you have to remove the hordes of paths to Unix utilities that are in
there that people that have never used Unix are unlikely to know about
(what's a bash, what's an emacs?).

} 
} 2a) Extend File::basename.pl to extract other interesting properties of
} filenames, and to build filenames that will work on the target.
} 
} 2b) Replace File::basename.pl with an OO module that has constructors, and
} parsers.
} 
} Not knowing any better, I propose that the characters slash "/", backslash
} "\", colon ":", left and right square bracket "[" and "]" be treated
} specially for cross-platform purposes.

No, I'm not sure I like this.  What I would prefer under MacPerl is
that anything that is legal on a Mac won't have to be encoded, which
means, essentially, that any name without : and less than 32 characters
in length is legal and should be accepted by a basename or
basename-like routine.  There should be no reserved characters other
than those forbidden by the local OS.  This is straightforward on Macs
and Unix (and I assume on DOS).  If you're doing cross platform work,
you might want to teach it what's illegal on various platforms, and to
tell it to encode characters illegal on that platform if the path would
otherwise work but throw an error if it wouldn't, or something. But
there shouldn't be any restrictions on the local character set or name
length beside what already exist.

} 
} Bob Dalgleish   bob.dalgleish@sasknet.sk.ca
} Web Page        http://www.sasknet.com/~dalgl/
} 
} 
} 
---
--------
Paul J. Schinder
NASA Goddard Space Flight Center,
Code 693, Greenbelt, MD 20771 USA
schinder@pjstoaster.pg.md.us