What I'm wondering is whether it's possible to simply remove the CRLF
for the very last row rather than doing the 2 null replace?

I hope that's a bit clearer.

Much clearer; thank you.

I'll reproduce the relevant IEEE 1003.1 (POSIX) standard below - maybe it
will clear some things up as far as what's valid or not, and where any
changes would ideally be made (hint: it's not in the CPYTOIMPF code ;-)

But to answer the question, there are two nice approaches mentioned at
http://social.msdn.microsoft.com. Bring up google and type in the search
box: site:social.msdn.microsoft.com correct/best size

That'll bring you right to it (or it right to you). Good luck.

As promised...

IEEE Standard 1003.1 (aka POSIX) has these definitions:

3.205 Line

A sequence of zero or more non-<newline>s plus a terminating <newline>.

3.392 Text File

A file that contains characters organized into one or more lines. The
lines do not contain NUL characters and none can exceed {LINE_MAX} bytes
in length, including the . Although IEEE Std 1003.1-2001 does not
distinguish between text files and binary files (see the ISO C standard),

many utilities only produce predictable or meaningful output when
operating on text files. The standard utilities that have such
restrictions always specify "text files" in their STDIN or INPUT FILES

Note that by this definition that many of us hold sacred, a line is ended
by newline, not by a zero byte. By extension, any line that doesn't
contain a new-line character/sequence, is not a valid line. You can see
ramifications of not ending lines according to this standard when you use
line counters and the like, among other things.

Dennis Lovelady
"I would rather men should ask why no statue has been erected in my honor,
than why one has."
-- Marcus Cato (2nd century BC)"It is better to deserve honors and
not have them than to have them and not deserve them."
-- Mark Twain

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].