Re: [MacPerl] Writing line-ending agnostic scripts?

["Jon S. Jaques" <jjaques@grovehillsys.com>]

 Hi All,

> Similar problems occur in lots of other cases where files from different
> platforms are involved, especially when they're acquired in archives and
no
> implicit conversion is done.

> I'd like best if MacPerl had an option to treat \015, \012 and \015\012 as
> line endings. Thinking of it this might be very useful when Rhapsody
> arrives as we probably have to get used to different line-endings in files
> created on the same machine.

There's more to it than that, but I am currently working on a solution; I
have not started actually writing a script yet, as I personally don't have a
Mac to develop on. An important thing to remember, however, is that my
primary situation is 30 Macs and 2 PC's all accessing the same files on an
NT3.51 Alpha server, which has to provide special services for the Macs to
be able to access the prepared disks. The file problems are identical,
however, to the files being stored in a "pure" Mac networked environment, as
I assist in the administration of one of those as well.

Here is a copy of what I have learned from Matthias:

> In message <199707310106.VAA01785@relay1.pair.com> you write:
> > In message <199707300029.UAA29291@relay1.pair.com> you write:
>> >> Unfortunately, the Macs can't be trusted to do FTP, thanks to the
>> >> creator-type.
>
>>>  Actually, precisely thanks to the creator type, proper Mac clients
*are*
>>>  trustable to do FTP. Fetch, available from
>
>> Well, maybe it's for different reasons than I thought, I'd admit that,
but
>> there seems to be a problem with different types of apps resetting the
>> creator-type, then. Apps such as SiteMill, and Netscape Gold, and
possibly
>> other WYSIWYG editors are liable to do *their* own, as well. Bad news!

> Ah, you're really talking about creator types. At least for text files,
you
> should usually ignore creator types. A file type of TEXT is what you
should
> check for.

>> Well, yes. But I want all ASCII to be Unix ASCII, so that it won't be
>> incomprehensible to the server.

> Fetch has an option to translate to ISO 8859-1 on text uploads, which is
> probably what you want (ISO 8859-1 is the character set used on WWW
pages).

>> I found a ref. on the MacPerl list about the
>> extended ASCII characters accidentally getting converted to
>> control-characters during transfers, which is really bad. Also, what if
>> somebody edits a file with SimpleText? That dumb little app is well known
>> for putting bogus binary bits into files, and it doesn't even have any
way
> >of viewing them!

> Well, if specific control character problems occur, you can still write a
Perl
> preprocessing filter to catch those.

>>>  I suggest that you try the possibilities of Fetch & Internet Config
first;
>> if
>>>  those fail to yield a perfect solution, I'll be glad to assist you in
>> writing a
>> > script to tweak the rest (Creators are manipulated with
>> MacPerl::SetFileInfo,
>>>  by the way).
>>
>> Cool! I'll be taking a look into SetFileInfo, and see what I can see. It
>> might be enough, however, to simply script your way through all of the
known
>> ASCII types, correct any extended characters which might map to a control
>> character, and then fix the line feeds. In my case, all web-destined
files
> >are stored on an NT server, so they may not *ever* need to be encoded
with
> >the Mac schema. (In other words, indiscriminately set them all to "\n's"
and
> >then they should be safe to transfer as ASCII, no?)

> Yes, but you probably won't see any other line feeds in a proper Mac text
file
> anyway, so this step might be redundant.

> Matthias




***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch