RE: Eliminate EOF (Ctrl-Z

[Carl Distefano CLDistefano@xxxxxxxx]

Reply to note from Peter Brown  Tue, 7 Dec 1999
06:41:26 -0000

-> Many thanks to Robert for the tip. EOF is not the problem
-> itself, but it leads to what I think will be the solution:

Actually, the tip was mine (though the technique of concatenating
the subject file with a non-existent file indeed originates with
Robert).

-> So (I think) all I have to figure is how to get 1mail.prn to
-> zap the EOF and replace with ascii-13, ascii-13, ascii-10. (The
-> FE< line has to end with just those characters.)

Can't be, Peter -- it's just too tortured, even for Microsoft....

Wait a minute! Bingo! I got it. It *is* the EOF, pure and simple.
Remember, the mystery here was why TYFing with MAIL.PRN worked in
Xy4 but not Xy3 -- Outlook "found" the file created by 4 but not by
3. Well, it turns out that there IS a difference between the two
files (I just tested): You guessed it, the Xy3 file has the EOF!
Xy3 ignores the bare FE< specification in MAIL.PRN (meaning no end-
of-file char), whereas Xy4 honors it and produces a EOF-less file.

So now there are a zillion and ONE reasons to use 4! But if you
absolutely must use 3, then all you should have to do is zap the EOF
from the output file before importing it into Outlook. It should
work!

As for the Ascii-26 being replaced by Ascii-13 -- I dunno. Xy3
produces some pretty erratic results with MAIL.PRN -- files littered
with lone Ascii-10's, for instance -- and that Ascii-13 may be
another of its idiosyncrasies. Probably when you save as .TXT in
Word it appends a 13+10 CrLf if the file doesn't already have a
canonical line-end -- which a lone Ascii-13, of course, is not.
Which is how you end up with 13+13+10. But I'm betting that none of
that matters once the EOF is out of the way. Try it!

--------------
Carl Distefano
CLDistefano@xxxxxxxx
http://users.datarealm.com/xywwweb/