[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] MacPerl bugs?

At 19.03 -0400 1999.06.07, Joshua Juran wrote:
>On Wed, 2 Jun 1999, Chris Nandor wrote:
>> At 9.46 -0400 1999.06.02, Scott Prince wrote:
>> >>/mac/ won't match $^O on MacPerl.  It might match some other OS's, like
>> >>machten.  $^O for MacPerl is "MacOS".  See perlport.pod (on
>> >>http://pudge.net/macperl/ and in perl5.004_05 and higher).
>Question:  what if someone were to create a version of MacPerl that
>acted like it was unix?  (E.g. pathnames, stat output, etc.)  What should
>$^0 be?

$^O, not $^0.  And the answer is undefined.  When someone does it, they
would probably go onto the perl porters mailing list and it would be
discussed.  I frankly think it would be a bad idea, but to each his own.  I
do have a question for you, though: what could possibly be changed about
MacPerl's stat output?  The only nonstandard thing about it is atime and
mtime are the same, because there is no atime data stored on Mac OS.  Do
you want to rewrite the filesystem?

>What if you want to be able to deal with non-local files?  It seems to be
>that text-mode input should be able to handle any kind of newline
>automatically, and output should use a user-settable preference,
>defaulting to the local convention.

There are many reasons why this is a bad idea.  First, it will never be
implemented in MacPerl unless it is implemented in Unix perl.  Second, it
probably won't ever be implemented in Unix perl.  I'll let Matthias discuss

>I suspect this might upset a lot of unix users who are used to using
>text-mode I/O calls for binary I/O tasks, though.

Only one major OS treats binary and text data differently, and it isn't Mac
OS or Unix.  And I hate it having to deal with that garbage when I am using
that OS.  There's no way I would ever regularly use a perl that
transparently translated my newlines, and I wouldn't go very far out of my
way to make my programs work on such a perl, either.  And I know I am not

>I think this change should be made at the stdio level, so all text I/O
>applications can take advantage of it, instead of being forced to use
>binary I/O just to be compatible with other platforms.  But short of that,
>it would be a useful change to MacPerl.

I disagree.  I don't see much benefit in it.  Especially when it is
relatively simple to take care of it in your own program.

Chris Nandor          mailto:pudge@pobox.com         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

===== Want to unsubscribe from this list?
===== Send mail with body "unsubscribe" to macperl-request@macperl.org