Re: How to fix CRLF stuff...


Subject: Re: How to fix CRLF stuff...
From: Jeremy Buchmann (jeremy@wellsgaming.com)
Date: Wed Feb 14 2001 - 13:21:09 EST


(I have three replies quoted here...please note who it is I'm quoting)

> Bob Rogers:
> I don't know about less, but I understand some apps just look for NUL
> characters, a dead giveaway for a binary file (at least in the Unix
> world).

A good idea...or as someone else pointed out, magic is what the 'file'
command uses to figure out what kind of file a file it is.

> Bob Rogers:
> Nothing is too simple if it works. ;-} But isn't this likely to get
> confused by Mac characters and/or internal markup? If you create some
> nontrivial test files (e.g. with font changes, bullet characters) in
> SimpleText and save them to a netatalk share, what does `less' do with
> them?

Formatting of any kind implies a non-text document. Those shouldn't be
translated.

The only reason for translation (AFAIK) is to make text documents useable on
the Unix side (my primary interest).

> Matthew Wilson:
> just put some european characters in the file, like a 'u' with the two
> dots above it. Less will warn you that it may be binary. (try reading a
> Pike readme file)

[disclaimer: what I know about 8-bit ascii or 2-byte chars couldn't fill a
thimble]

Do these chars have a unique ascii code? If so, they can be recognized as
text. If not, then people with those chars in their documents might be SOL.
C'est la vie.

As far as less is concerened, I was just using it as a simple example
showing that some programs can differentiate between text and binary files.

> Matthew Wilson:
> alternatively, you could still have a file that you don't want translated
> that didn't happen to have any 'funny' characters in it.

That is possible, (like with tar'ed text files?), but either way, we're
playing with the law of averages. Does Finder always know what is really a
text file and what isn't? Hell no. Especially not in a heterogenous
environment. Hell, half of the files on my desktop have the "blank" icon.
All I'm saying is, as long as our solution won't be perfect, why make it
difficult?

> Peter DiCamillo:
> There is a much simpler approach if the goal is only to avoid the
> "corruption" that happens when applications like the Finder and
> StuffIt change the type to TEXT after creating the file. While I
> like the idea of comprehensive solution to the CR/LF problem, this
> simpler approach would solve the only serious problem we have with it
> here. My idea is the following:
>
> 1. Define a new "suppress CR/LF translation" bit in the AppleDouble
> file. The bit would be off for files created by previous versions of
> netatalk, and assumed off if the AppleDouble file isn't present.

Ok, I follow so far...

> Peter DiCamillo:
> 2. When afpd creates a new file, the suppress translation bit is set
> if the file is not translated at that time.

Ok...but how does afpd know to translate the file? This is the problem I'm
talking about...it seems you're talking about the problem of keeping track
of what has or has not been translated.

> Peter DiCamillo:
> With this approach, a Mac user could use the Finder to copy a TEXT
> file to a netatalk volume and back again without the file changing,
> although it would not be translated for Unix users.

This is how it works now unless you specifically set the crlf option in one
of the config files...how has this changed anything?

> Peter DiCamillo:
> This would be
> compatible with a more comprehensive solution where afpd could be
> told to either translate or not translate a given file. When the
> suppress bit is off, setting the file's type to TEXT would force
> translation, and would also be useful to the Mac user.

Now I'm confused...how do we set the file's type to TEXT? Isn't that the
problem...as of OS 8, Finder doesn't set the type before copying?

-- Jeremy [jeremy@wellsgaming.com]



This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:32 EDT