Re: [MacPerl] Meet the Newline, same as the old line (longish rant)

[daver@idiom.com (David Ray)]

Speaking for myself, the only situations where MacPerl needs to be completely portable is when I'm programming perl CGI's that run on Mac or Unix web servers. The Mac implentation of Web - perl CGI interaction (namely, Matthais' PCGI program) automatically translates newline characters into the same ones commonly used by Unix and the Internet. So if I use \n in my scripts, I can read/write text files in the format normal for for either OS. The \n is mapped to the standard ascii character that is associated with that OS. So from my stadpoint, I would rather not map Type 1 differently, and I support keeping it the way it is.

-Dave

At 5:08 PM 10/22/97, Matthias Ulrich Neeracher wrote:
>  1) Files KNOWN to be text: Everything that is parsed, whether it is the
>     main script or files included via use, require, or do.
>  2) Files KNOWN to be binary: Files on which the user has called binmode.
>  3) Files ASSUMED to be text: Files on which the <> operator is used and
>     $/ is set to "\n" or "".
>  4) Files about which nothing is known.
> 
> It is fairly uncontroversial that on category (1), every transformation would
> be legitimate, and that on category (2), no transformation is legitimate.
> 
> Currently, UNIX perl and MacPerl do not perform any newline
> transformations. DOSish perls transform all files in category 1, 3, and 4.
>.....
> So, faced with those choices, I've decided to do nothing for the
> moment. Specificallly, I will NOT:
> 
>  - Transform EOL characters in files I read generally.
>  - Change the definition of \n.
>  - Accept '/' as a path separator.
>  - Change the time() epoch to 1970.



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