[Date Prev][Date Next][Thread Prev][Thread Next]
[Search]
[Date Index]
[Thread Index]
Re: [MacPerl] MacPerl bugs?
At 7:16 PM -0400 1999-06-07, Chris Nandor wrote:
>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?
You're right, the perl porters list is the place to discuss it. But since
you asked, perl's stat return's mtime as seconds since 1970, versus
MacPerl's 1904. And yes, I intend to rewrite the filesystem. One of my
projects is to write a command shell for Mac OS, as well as a development
environment that is as POSIX-like as can be arranged. The point? To allow
deployment of unix-based software with minimal or no revision. Since many
programs assume a unix filing system, that project calls for implementing
one.
>>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>.
Good -- so it's well known that this is an issue. Basically, I have my
Linux home dir mounted as a volume, and I want my scripts and data files to
be usable on both Linux and Mac OS. I don't much care which line breaks
they actually use. I suspect this to be more of an issue when Mac OS X
gets popular.
>>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.
But they have different ideas of what text is, which is a different, but
related problem.
>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
Yeah, I think it's a bad idea to put printer instruction codes in a file
instead of device-independent content also. (That way, you can just dump
the file to the printer instead of using a very simple printing utility
that would perform the minimal processing.) But I think it was also
foolish for the Mac to use a newline that no other system (that I'm aware
of) uses. The early incarnation of "Think different", I guess. In any
case, we now have a portability problem.
>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.
Okay, what if you could set a variable or call textmode() to specifically
request automatic translation? No performance hit, and doesn't break
xenophobic scripts, unless you ask for it.
>>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.
It was relatively simple to handle DOS text files by stripping leading
linefeeds. But how would I handle unix text files without knowing in
advance that's what they are? I guess I can check for a linefeed at the
end (or anywhere, just in case) in the first line. (DOS files don't have
linefeeds before the first CR.) If so, reset the file and set LF as the
newline char. Sounds like a pain, though, and slurps in the whole file at
first. Any better ideas?
Josh
--
Joshua Juran Metamage Software Creations
=) Tools for Wizards
wanderer@metamage.com
<http://www.metamage.com/> * Creation at the highest state of the art *
===== Want to unsubscribe from this list?
===== Send mail with body "unsubscribe" to macperl-request@macperl.org