Re: [MacPerl] MacPerl bugs?

[Chris Nandor <pudge@pobox.com>]

At 5.14 -0400 1999.06.24, Joshua Juran wrote:
>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.

Hm.  stat() still acts like Unix stat(): it, as documented, returns seconds
since the epoch.  However, if you must have seconds since the Unix epoch,
not the Mac epoch, you could just write a module that would override
stat().  File::stat does this already, but for a different purpose.  See it
for an example of how you could do it.  You could use this module of yours
on Unix and Mac OS, making the time adjustments appropriately.  You could
also override other functions where you want the Unix epoch (like localtime
and time).


>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.

Write a new filesystem, or write a new system of asking for files?  Sean
Burke has a module called Mac::FileSpec::Unixish which translates Unix
paths to Mac paths.  So you can store filenames in Unix style, and call
nativize($path), and it will be turned into a Mac path for Mac OS, or else
left as Unix style.  Alternatively, you can be truly as portable as
possible and use File::Spec to construct your paths, which will work on
most operating systems.


>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.

As Matthias and Paul suggested, you could have some code to check for the
newline.


>>>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.

Yes, but my point is that Mac users are in the same boat.  I use text IO
calls for binary IO tasks on Mac OS, because it is all the same to Mac OS.


>>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.

As Matthias pointed out, this was not a bad design decision.  It was an
unlucky guess, at worst.


>>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.

You can do this now:

  open(FILE, "<foo") or die $!;
  textmode(FILE);

  # do stuff

You just have to write textmode(), which is not a big problem.  Here's
something that might work for you:

  # require "textmode.pl";
  sub textmode (*) {
      my $fh = $_[0];
      undef $/;
      my $pos = tell $fh;
      seek $fh, 0, 0 or return;
      until ($/) {
          read $fh, my $bytes, 1024 or return;
          ($/) = ($bytes =~ /(\015?\012|\015)$/);
      }
      seek $fh, $pos, 0 or return;
      1;
  }
  1;

The problem with this approach is it changes $/ (input record separator)
globally and permanently unless you help it along.  Basically, you'd need
to do this to protect yourself sometimes:

  require "textmode.plx";
  {
    local $/;
    open FOO, "<foo" or die $!;
    textmode(FOO);
    # do stuff ...
  }

  # now $/ is back to normal

It differs from binmode() in that binmode() gets applied to a specific
filehandle.  Doing that here would not solve the whole problem anyway,
because chomp() has nothing to do with filehandles.  Here's another idea,
though: there could be a tied filehandle to translate every thing to local
newline on read, without touching $/ (well, only internal to the tied class
with dynamic scoping).  I have a prototype for it, but it would need a lot
of details worked out and discussed to decide on how each function would
behave.

--
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