Re: [MacPerl] Re: Newlines

[pvhp@forte.com (Peter Prymmer)]

rrathe@dean.med.ufl.edu, mac-perl@iis.ee.ethz.ch
Subj:	Re: [MacPerl] Re: Newlines

Richard Rathe <rrathe@dean.med.ufl.edu>

>I still find it amazing that Perl is non-portable BY DESIGN!?! The concept
>of end-of-line is so universal, I fail to understand why this problem isn't
>"taken care of" behind the scenes...

It is taken care of: on UNIX C<print "Hello World\n";> results in a different
output stream than on the Mac or DOSish systems.  This is the same as for "\n"
in C on those systems as well as cout << endl in C++ on those systems.
You can even run a number of UNIX scripts with line feeds on a Mac with 
no translation at all.  It is simply better to set up your shop to handle the
translation for those scripts where it does matter (typically involving formats
and here-documents, etc.)


>UNIX script in existence!) Another example is the directory delimiter. What
>harm would be done if MacPerl automatically changed '/' to ':' and back
>again when it works on directories and files?

I think that even I can answer this one: the ease with which one can place a 
'/' into a file or folder name on the MacOS desktop precludes the use of that
as the *default* directory separator.  Simple workarounds to use '/' like:

   if ($^O =~ /MacOS/) { $dir =~ s#\:#/#g  }

are rather easy to write and use but serve a special purpose and will be 
limited to working on $dir trees where you _know_ that a '/' was not used 
in a file or folder name.  You simply cannot assume that in general on a Mac.  

It is certainly true that a universal hierarchical file system (e.g. 
DCE DFS, the http "file system", etc.); will likely use '/' rather 
than ':' or '\' or '.' as directory separators.  But such schemes limit 
what you do in a given platform's native tongue.  Bear in mind that many folks
use MacPerl to program for the Macintosh and not for the Mac and UNIX and 
Windows combined.  The person who takes on the challenge of the latter task
has more work to do, while the person who handles the former task has an easier 
work load.  I personally think that this is as it should be.  

Easing the burden on the cross-platform developer is another goal (and one that 
I must constantly strive towards since I have to write perl scripts for those 
OSes mentioned as well as VMS, MVS, and DOS :-) but it will likely be done via 
optional things like modules and/or optional unicode compiled support - all of 
which will slow perl down and not help the single platform user one bit at all.

Peter Prymmer


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