Certainly, in my experience, LF, CR, or CRLF are considered
as EOL (in ..IX, MAC, PC OSs). Going way back, these things
came from input devices such as the IBM 1050 which was an
early typewriter terminal. It had the charming attribute
that the "return" key did just that (returned the carriage
as on a typewriter) Then, of course a line feed was needed
to start on the typewriter... To get the input line entered into
the computer one had to explicitly enter a EOT character - what
fun... I think this idea of a typewriter crept into DOS but it
was considered "convenient" to imply that the return indicated
EOT as well... This "clear thinking" was likely a result of
people not looking at things outside of IBM (a mistake IMHO)...
All of these early input devices ended a line to indicate
taking action in an attached processor - the fact that such
input was streamed into memory (and maybe saved on a file)
would indicate that all lines -- including the last one --
ended with a designated character (or two on the 1050 and PC)
Nowhere in the history of how files evolved do I see/remember
a different view - do you know of some thread of computer
evolution that was different and leads you to say it is
relative?
Two memories related to this amuse me. One was in my very
early days using APL from a 1050. The APL system was the
"original one" in IBM Yorktown Heights Research. My 1050
was in Boulder Colorado. APL\360 had a command to do iMsg e.g.
)OPR WHY IS THE SYSTEM SO SLOW?
would post a message to the system operator console. On the 1050
I could send a multi-line message in a single go by not adding
the EOT signal until after the last of the lines. As I type
this story, I realize that I do not know/remember if the 1050 EOT
had to immediately follow a "return" - (and maybe that is just
such a thread as I asked if you knew of!) Such multi-line operator
messages confused the operator who wondered how it was possible...
The other instance I know of about EOL being "strange" is in the
TIFF type 2 (FAX) file structure definition. The standard for
that states that all (scan) lines of the document shall begin
(not end) with a New Line character. I ran into cases where
programs didn't do that and while the authors admitted that
it was a bug, the loss of the first scan line on a FAX was
considered acceptable instead of fixing the programs...
Maybe there is some "logic" like that behind Excel not producing
files with a terminating line end - but you must admit that not
having a line end on the last line certainly could cause one to
wonder if the file was complete, or was the victim of an
accidental ending... Of course, having a line end doesn't insure
that there wasn't an explosion at the source of the data just as
the last EOL was put in place but before the file was completed -
But but EOL just before EOF does provide comfort (not to mention
convenience) that things are OK....
As an example of why I consider the Excel behavior a bug, consider
trying to catenate two Excel text output files together, then using
them as input to Excel. The missing line end becomes an issue..
In any case, because of programs like Excel, any line reading
program should do its best to provide all the data - and should
likely alert the user that things didn't end cleanly...
- joey
At 10:32 -0400 2006/05/16, Alain Miville de Chêne wrote:
It is all relative.
The LF can be seen (as you do) as "end of line" or as "new line".
In the first case, all lines should end with "end of line".
In the second, LF cuts one line from another.
When editing a text file, and requesting to
place the cursor at end of file, with no LF at
the end the cursor is placed after the last
character somewhere to the right at the end of
line. With an LF at the end, it is placed at the
beginning of an empty line at the end.
I am not sure it is a M$ problem.
Joey K Tuttle wrote:
...
Actually, it needs to be dealt with. Some programs produce
files without a final end of line -- e.g. M$ Excel text files.
I have never understood how they could do that with good
conscience...
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
