× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




On Sat, 21 Jan 2006, Jim Franz wrote:

Am writing a ascii text file, fixed field length to be ftp'd to a US Post Office server. The following is an exact quote from the specs (Pub 91) "a line feed and carriage return is needed at the end of every record except the last record of the electronic file"

Way back when, the standard on Apple systems was CR only -- no linefeed. On DOS it was CRLF (both chars) and on Unix it was only linefeed. I have a feeling that this paragraph was originally intended to say "You need the line feed, in addition to the carriage return at the end of every record except the last." The point was to stress that both are required, instead of just one or the other. I could be wrong, but that's my guess.

At any rate, if they do want LFCR, it should be easy to change your code and re-generate the file.

2. I have never heard of leaving off the CRLF from the last record? This file is a Header record (130 bytes), followed by Detail 1 (200 bytes), Detail 2 (352 bytes),Detail 1, Detail 2, etc. No Trailer record. Detail 2 does have a 7 byte alpha field at end of record that must contain spaces.

Remember, CRLF originated as printer control characters. CR returns the carriage to the left-hand side of the page. In other words, moves the print head back to column 1 of the same line you were printing on. LF feeds down 1 line, but doesn't affect which column you're printing in. So, CRLF together would move to the start of the next line on the page.

What you should do with the last record was an area of debate.

It doesn't make sense for a printer to do a CRLF on the last line of a document. What are you moving to the next line for if the printing is done? In fact, if you happened to end on the last line of the page, it could move up and start a new page. Since the last line of a document is often followed by a form feed character (FF) this would cause a page of paper to be wasted.

On the screen, however, the CRLF was thought of as the logical end of a line (or "record") so some programmers came to the conclusion that it should exist on all lines of the file. This led to some descrepancies in software:

a) Some software dropped the last line of a text file if it didn't have CRLF at the end.

b) Some software would automatically add the CRLF to the last record if it was missing.

c) Some software expected there there would never be a CRLF on the last record, so if you put one it'd think there was another record -- and since that record would be empty (since there's nothing after the CRLF) it would signal an error or add a blank entry to a database, etc, depending on how the program worked and what it did.

d) Some software would use the CRLF at tne end to keep track of where the cursor should be positioned when the document is loaded into a text editor or displayed. If the CRLF existed, it'd put the cursor on the line below, otherwise it'd be placed at the end of the last line. This type of software would painstakingly preseve the formatting exactly as your program wrote it or user typed it.

So there were lots of different interpretations of how the last record should work. Naturally, this led to incompatibilities.

I suspect that's why the postal standard is telling you that you don't need/want a CRLF on the last record -- to make it clear to you which convention they expect you to follow.


Without final CRLF will ftp have a problem?


It won't make any difference to FTP.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.