Subject: Re: CRLF fun stuff again...

From: Duncan Sinclair <[email-masked]>
Date: Sat, 03 Feb 2001 12:08:28 +0000

Hi Folks,

I wrote:
>Until now, every time I mention this problem, people tell me that I
>shouldn't want to do cr/lf translation, and it's an ugly hack.  My reply
>is that it is necessary for cross platform file manipulation, and I
>really, actually, want it, thank you very much.

Donald Lee writes:
>If I may add my two cents, I think it's a bad idea for the filesystem to
>effectively blindly fondle and convert the data.  There are plenty of tools
>out there, like bbedit, that handle text files regardless of how their
>line endings are done.
>
>The downside of a problem with the CR/LF "feature" is irretrievably corrupted
>data.  What you get for this is arguably a minor "convenience".
>
>I think it's a bad trade.
>
>I keep it turned off, and recommend this to all who ask.

This is the sort of thing I mean.  I know that BBEdit handles Unix
files transparently.  That's not what I'm interested in.  I want to
edit Mac-produced files on the Unix end.  Vi doesn't "do" Mac-style
line endings.  Nor does any other unix utility.  Nor should they.

Typical example... I have users that edit HTML pages using their
favourite HTML editor and then copy their pages to my server.  I later
may want to edit their pages from my Sun.  I first have to do the cr/lf
conversion myself.  I wouldn't have to do this if the cr/lf translation
worked properly.

If the cr/lf translation is done right there is _no_ corruption of
data, unless you try to do silly thing like edit binary files with
a text editor - a guarenteed way of corrupting data without any help
from the filesystem.

 [ A correctly configured netatalk setup only does cr/lf translation on
 Mac-produced TEXT files, and Unix-created files that by their
 extension are recognised as text by netatalk.  You should not configure
 netatalk to assume that unix files are text when it doesn't have a
 recognised extension. ]

If you don't want to use the cr/lf translation, then don't, but while
the feature exists in netatalk, it would be nice if it actually worked.

Cheers,

Duncan.

---

From: Paul Schinder <[email-masked]>
Date: Sat, 3 Feb 2001 07:50:27 -0500

>line endings.  Nor does any other unix utility.  Nor should they.

GNU emacs has no problems reading files with Mac end-of-line.  20.7 
even tells you what the line endings are (like Alpha, for example) 
and as I just verified, uses Mac EOL if you add lines to a Mac file.

xemacs, on the other hand, can't read Mac files.

-- 
--
Paul J. Schinder
NASA Goddard Space Flight Center
Code 693
[email-masked]

---

From: "Craig White" <[email-masked]>
Date: Sat, 3 Feb 2001 10:14:07 -0700

Perhaps someone can give me a quick fix on this.

When I print from a Macintosh on the network, the jobs don't print and I get
the following in my syslog...

Feb  2 22:29:03 barney papd[857]: child 22961 for "felix2" from 65499.251
Feb  2 22:29:13 barney papd[22961]: lp_conn_unix connect /dev/printer:
Connection refused
Feb  2 22:29:13 barney papd[22961]: lp_print: lp_conn_unix: Connection
refused
Feb  2 22:29:13 barney papd[857]: child 22961 done

if I restart the lpd daemon, I get the message on screen

permissions of XXXXXXXbarney.azapple.com are 640 not 600
owner/group of XXXXXXXbarney.azapple.com are 0/0 not 4/7
changing ownership of XXXXXXXbarney.azapple.com to 4/7

and then the job will print.

my papd.conf...

felix2:\
	:pr=lp:\
	:op=lp:\
	:pd=/usr/lib/atalk/HPLJ_4M.PPD:

my /etc/printcap...
#
# This printcap is being created with printtool v.3.41
# Any changes made here manually will be lost if printtool
# is run later on.
# The presence of this header means that no printcap
# existed when printtool was run.
#
##PRINTTOOL3## LOCAL POSTSCRIPT 600x600 letter {} PostScript Default {}
lp|Felix2:sd=/var/spool/lpd/lp:sh:mx#0:if=/var/spool/lpd/lp/filter:lp=/dev/l
p0:

I've tried different op= and even without the op statement at all but it
doesn't seem to matter. How do I get print jobs to user.group 4.7 and
permissions to 600 and not 640 or simply, how can I print jobs that are
acceptable to lpd?

----:----|----:----|----:----|----:----|----:----|----:----|
- Craig White - PO Box 8634 - Scottsdale, Arizona - 85252
- e-mail address ................ - [email-masked]
- world wide web address ........ - http://www.AzApple.com
- e-mail my pager address ....... - [email-masked]
- cellular phone ................ - (602) 377-9752
- voice/facsimile ............... - (480) 945-8445
----:----|----:----|----:----|----:----|----:----|----:----|

---

From: Carsten Neumann <[email-masked]>
Date: Sat, 3 Feb 2001 22:10:09 +0100

> permissions to 600 and not 640 or simply, how can I print jobs that are

Change the entry in your papd.conf as follows:

felix2:\
 :pr=|/usr/bin/lpr -Plp:\
 :op=lp:\

That did it for me - I had very similar problems.

Regards

	Carsten

---

From: Lee Sheridan <[email-masked]>
Date: Sun, 4 Feb 2001 01:12:29 -0500 (EST)

> and as I just verified, uses Mac EOL if you add lines to a Mac file.

And *EVERYBODY* uses GNU emacs, right?  :)

-- 
__________________________________________________________________________
Lee Sheridan                            301.286.5898 voice
NASA / Goddard Space Flight Center      [email-masked]
Computer Sciences Corporation 		Building 28, Room S241
Code 931

---

From: Matthew Geier <[email-masked]>
Date: Mon, 05 Feb 2001 11:07:42 +1100

> conversion myself.  I wouldn't have to do this if the cr/lf translation

 'vim' does Mac and PC style eol conventions and can auto detect. VIM is
often shipped as the 'vi' on Linux distributions.

 It is worth noting that the Samba team have point blank refused to add
any form of 'translation' to Samba. It serves files exactly 'as is'.
They argue that EOL conventions are an Application problem and its not
the file servers job to try and guess what the user is up to and mess
around with the contents of the files.

-- 
Matthew Geier			[email-masked]
Arts IT Unit			+61 2 9351 4713
Sydney University

---

From: Steve Freitas <[email-masked]>
Date: Fri, 09 Feb 2001 13:34:14 -0800

> around with the contents of the files.

I think that is absolutely the right thing to do. I've had this CR/LF thing
munge up whole ISOs for me, even when it's turned off. Sure, the option
should be left in, but I don't want my fileserver to, by default, play
guessing games with my linefeeds, which is what it seems to be doing, as
least as far as my inexperienced eyes can tell (referencing my much earlier
thread on this topic).

When you've got to remember to add a line to AppleVolumes.system just to
keep a file with a new suffix from being corrupted, that's just bad.

Jeff, what do you think? :-)

Steve

---

From: jeff <[email-masked]>
Date: Fri, 09 Feb 2001 16:42:51 -0500

> Jeff, what do you think? :-)

Munging files is bad. If we want to move CRLF translation to a
compile-time option, that's a fine solution; those who want to compile
it in, can.

If an Apple (tm) AppleShareIP server doesn't do the translation, we
probably shouldn't do it by default, either. Reliability, then neat
features.

jeff

(We might want to nudge the Samba people gently about the
--with-netatalk support in Samba, and de-stub-ing it sometime.)