1 byte more?

[Gary W. Swearingen]

Mac Mason <mac at cs.hmc.edu> writes:

> As I recall, the convention is than UNIX text files should always end with a
> newline character. I can certainly envision situations where you might not
> want to have the extra \n, but it makes intuitive sense for it to be there:
> having the first half of a line in one file and the second half in another
> file feels very strange to me...

Does it really make intuitive sense to have a "newline" where there is
no new line?  (Apparently, a file's first line is not necessarily a new
line, depending on how it's used.)

I guess the convention got started because, unlike typewriters, shells
(and Teletypes, IIRC) don't do anything useful until the "carriage
return" key is used, at which time, they start a new line with
"newline" so the command output, if any, will start on a new line,
whether it wants to or not.  So their prompts don't start a new line
by themselves, execting one to have just been started by the command
interpreter when the command has no output or by the command when the
command has output.  That forced commands like "echo" to normally end
with a "newline".  And for commands like "cat" which don't end with a
"newline", it pushed the extra "newline" into the text file.

It would probably make more intuitive sense if the "carriage return"
key was interpreted more as "enter", leaving command output and
prompts to start each new line (even the first) with a "newline".
Oh well, that ship has sailed.

Most programs try to do their best to deal with text files that don't
end with a "newline", though it's sometimes debatable what is the best
way to handle both cases.