In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Heather Madrone) wrote:
> At 11:05 AM 11/24/2002 -0500, Chris Nandor wrote:
> >But back to the point: there's been some discussion in this threa on
> >workarounds, but my personal feeling is that this is a bug, or at best a
> >broken feature, in perl. Some time ago, the capability was added to perl to
> >recognize and filter CRLF files to work on Unix and LF to work on Windows
> >(grep for PERL_STRICT_CR in toke.c). However, this functionality was not
> >extended to CR files, as it should have been, IMO.
>
> I think you're right. It's easier to move back and forth from
> Windows to Solaris than it is to move from one side of the Mac
> house to the other. This is undoubtedly broken, not just in
> perl, but on the Macintosh in general.
Well, I'd say it is only broken in perl because there is some support for
it, but it is limited only to certain platforms. Otherwise I'd call it a
woefully missing feature.
I don't think it is, in the general case, broken on the Mac, however. They
can't just abandon CR, and they shouldn't have stuck with CR instead of
moving to LF. And CR itself wasn't broken to begin with. They really
didn't have many options; that is to say, the brokenness we encounter
because of the CR/LF differences are not indicative of a brokenness in the
OS, but just unfortunate confluence of events.
> Personally, I think that Apple would be wise to move to the Unix
> standard for text files. It would take several releases of
> confusion to do it, but that would be better than carrying
> forward this schizophrenia to future OS generations.
It has moved to the Unix standard. Many apps, however, have not entirely
made the adjustment.
> While they're at it, they might drop file resource forks.
Again, they essentially have. They are still supported because, as with the
CR issue, they cannot just abandon them. But most apps do not have them;
instead, the resource data is in separate files inside the packages. I
don't imagine support for resource forks will be dropped any time soon, but
resource forks aren't really used by new apps.
[pudge@bourque]$ perl -MFile::Find -MMac::Files -e 'find(sub{my $f =
$File::Find::name; return if ! -f || -l; my $catf = FSpGetCatInfo($_);
printf "%s : %d\n", $f, $catf->ioFlRLgLen if $catf->ioFlRLgLen}, shift)'
/Applications/
The above one-liner prints out the size of the resource fork in every file
under /Applications/ (ioFlRLgLen is the logical length of the resource fork,
while ioFlLgLen is the logical end of the data fork; the -s file test
operator and other file utilities, in perl and in Unix, only display the
data fork size, so it should always be the case that -s $f ==
$catf->ioFlLgLen).
Out of all my apps in there, I got hits in maybe a dozen or so, and the only
*Apple* apps were iMovie and DVD Player. It's fairly clear that resource
forks are being used less, and I imagine Apple is discouraging their use,
since they are no longer needed.
> If Apple doesn't want to give up its own peculiar file formats,
> then they ought to fix their Unix so it handles Macintosh files
> sensibly.
Apple assumes -- for right or wrong -- that people who use the Unix side of
things will be able to figure out how to deal with the resource forks, the
newlines, etc. (with tools such as CpMac, ditto) Let's face it: the Unix
user side of things is relatively minor in priority to most other things in
the OS. And really, it should be that way: it is used relatively little and
its users are smart enough to figure out workarounds. Life sucks sometimes.
;-)
--
Chris Nandor [EMAIL PROTECTED] http://pudge.net/
Open Source Development Network [EMAIL PROTECTED] http://osdn.com/
