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 it: <URL:http://pudge.net/macperl/newline.txt>. >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 alone. >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