Re: EOF

["..." yesss@xxxxxxxx]

≪ The question is, how did that extra [destructive midfile]
EOF get there, and why? ≫
		--Carlo Caballero 

Hi, Carlo. The most common way these days is merging
a downloaded file that was created by a dos word processor
and uploaded to the 'net using a binary protocol, thus
retaining the EOF char. More often than not, the word
processor was xyWrite. (It's a safe guess, e.g., that
the many Nando files that end with an EOF at some point
were saved in xyW.) Has some or all of your file been
on another platform sometime?

I download everything--all email and everything collected
from www--as one long file that I process with a xyWrite
3.57 xpl offline reader, and those EOFs used to be a
constant menace because what was at eof on a single file
might be midfile in my dl. Saving the file in xyW would lop
off everything after the EOF. Smart you, that you didn't.

XyWrite 4 has a setting (d 1A=1) that neutralizes midfile
EOFs, but docs warn against using the setting as a default
(for reasons that become obvious if you do). Normally, you'd
turn to it only you were aware of a file size discrepancy--
as you were, but that's not always the case.

I tried various unsatisfactory remedies that included
automated testing for displayed file length vs dir file
length and when there was a discrepancy shelling out
to xyDos 4 from the xyW3 CMline, or doing what you did
--removing those tell-tale vertical bars manually in
a gui app.

Finally, inspired by an eof-zapping .EXE Harry Binswanger
wrote with BASIC, I wrote my own with C because I wanted
to customize a xyW implementation. Mine is integrated
with an xpl manager--FIZFIX1A.EXE generates xpl reports
on its activities and file size info that xyW3 should have
va$ for but doesn't. Yet my .EXE is less than half the size
of Harry's, which demonstrates the bloat BASIC produces vs C,
not Harry's and my comparative programming skills. (I miss
ol' Harry.)

My xpl file-opener "do"es FIZFIX1A to every file I edit,
and my EOF headaches are a faded memory. The "do" is
invisible unless FIZFIX1A zaps a midfile EOF, in which
case the xpl manager issues a prompt of the former and
current displayed size length, pausing for a key press.
FIZFIX1A leaves the e-o-f EOF alone unless instructed to
remove it when a file is closed, as is desirable of course
for uploads that will use a binary protocol. (xyW4 afaik
has no built-in way either to rid a file of the e-o-f
EOF, but you can do that with a simple dos copy command.)
Hmmm, come to think of it, if a midfile EOF is present
FIZFIX1A may take off the e-o-f EOF too, but if so all
you need do to get a new one is save the file again
in xyW after destructive EOFs are gone; XyW gives you
only one e-o-f EOF.

What keeps me glued to xyWrite is that when you encounter a
prob like this unforeseen when it was written, it gracefully
digests a solution that make deferring to some other app
unnecessary. Astonishing piece of software. So, yes, you
can dl a xyW3 EOF-zapper from my www site, as part of
the !xyWise overlay.

≪ I never remember having trouble with the file, but
I wonder if XyWrite didn't break it into two or three
pieces and then reassemble it wrong ... ≫

I don't think so. ;) C'mon, Carlo. Have you ever known
xyW3.56 to do anything else that flaky? ... Ciao. 	--a

======================================= adpFisher  nyc
	xyWrite 3 supplements !xyWise and !xyWiz +
	Wolfgang Bechstein's seafaring adventures:
http://www.escape.com/~yesss/ ========================================