Live data from Hacker News

CRLF is obsolete and should be abolished

fossil-scm.org

211–220 of 273 posts

Re: CRLF is obsolete and should be abolished

#211
post #195

Earlier quoted context omitted.

>The latter is what typewriters do for the Return key. Minor correction: mechanical typewriters do not have a Return key, but they have both operations (line feed, as well as carriage return). The carriage return lever is typically rigged to also do line feed at the same time, by a preset amount of lines (which can be set to 0), or you can push the carriage without engaging line feed. Technically, the lever would do…

They didn't say "mechanical typewriters", just "typewriters". Electric typewriters did have a Return key that did work the way they described.

Indeed, I was clarifying that:

1) "Typewriters" in parent's comment didn't refer to mechanical typewriters, but

2) Line feed/carriage return semantics, as well as the UX of combining them into one action to proceed to the next line of text, predate electric typewriters and were effectively the same on mechanical ones.

As I wrote in the other comment, the subtle difference in semantics comes from teletypes, which couldn't advance the paper feed and return the carriage fast enough to print the next character in the timespan of one command.

Not that it applied to all teletypes, but it was the case for a very popular unit.

The makers of that machine deliberately didn't include a single command that would do CR/LF so that there'd be no way for the users to notice that.

The ordering, CR then LF, differs from the one on mechanical typewriters, where LF always precedes CR when you use the big lever, allowing one to use the same lever to produce blank lines without moving the carriage (in effect, doing LF LF LF ... LF CR).

On the teletypes though, CR LF ordering was, in any case, a lie, since in actuality, LF was happening somewhere in the middle of the carriage return, which took the time span of two commands.

The CR command had to precede LF on the teletype because it took longer, but since the mechanisms were independent, they could be executed at the same time.

This is the difference from mechanical typewriters.

Typing mechanism was also independent of CR and LF, and running CR + [type character] at the same time was bad. But having fixed-time-per-command simplified everything, so instead of waiting (..which means buffering - with potential overflow issues - or a protocol to tell the sending party to wait, which is a lot more complex), hacks like this were put in place.

My IBM selectric is not functional (got it as a repair project, didn't get to do it yet), so I can't verify, but I'd guess it doesn't need to do CR then LF, since it can simply not process input while the carriage is returning. It's OK for it to do CR and LF in any order, or simultaneously.

If the operator presses and releases a button during this time, the machine can simply do nothing; the operator will re-type the character the next instant, using the buffer in their head where the text ultimately comes from.

The teletypes didn't have that luxury, as the operator on the other end could be a computer, which was told it could send output at a certain rate, and by golly it did. Not processing a command would mean dropping data.

All that is to say that CR and LF are present on both typewriters and teletypes, with the following differences:

* mechanical typewriters always do LFCR due the mechanics of the carriage return lever, which was designed for a human operator;

* teletypes do CRLF because that's how they cope with the typist being a machine that can't be told to wait a bit until the carriage returns;

* and electric typewriters are somewhere in betwen and could do whatever, because the CR lever was replaced by the motor (like on a teletype), but the operator was still a human that could wait half a second without forgetting what it is that they wanted to type.

IMO, it's worth keeping CRLF around simply because it's a part of computer and technology history that spans nearly two centuries, from typewriters to Google docs.

Re: CRLF is obsolete and should be abolished

#212

Earlier quoted context omitted.

That appears to be an argument in favor of accepting bare-0ah, since as a positive statement that is the situation on the Internet today.

That was already motivated by Postel's Law. It's a step beyond to change what the strict form is; relying on the same to justify unilaterally transposing the form is asking too much of middlebox implementations of just about any line-oriented protocol, and possible violates Postel's Law itself by asserting the inverse.

I don't believe in Postel's Law, but I also don't believe in reverential adherence to standards documents. Make good engineering decisions on their own merits. This article is right: CRLF is dumb. You know who agrees with me about that? The IETF, in their (very old) informational RFC about the origins of CRLF in their protocols.

Re: CRLF is obsolete and should be abolished

#213
post #41

Counterpoint: Unix deciding on a non-standard line ending was always a mistake. It has produced decades of random incompatibility for no particular benefit. CRLF isn’t a convention: it’s two different pieces of the base terminal API. You have no idea how many programs rely on CR and LF working correctly.

But, like the article says, LF is not useful. I could always interpret LF as NL and if you send CRs too it won't break anything. If you know I'm interpreting LF that way you can just stop sending the CRs. That's what happened in Unix.

Re: CRLF is obsolete and should be abolished

#215
post #206

Earlier quoted context omitted.

Death pact? Jeez. Standards simply prevent people from having to waste time debugging dumb issues that rightfully could have been avoided.

They also add to the time wasted by not removing needless complexity in due time

The complexity of CRLF?

The balance here, of course, being backwards compatability. I'd sooner kill EBCDIC, bad ASCII and Code Pages than worry about CRLF if we didn't have to care about ancient systems.

Programming languages still retain C's operator precedence hierarchy even though it was itself meant to be a backwards compatible compromise and leads to errors around logical operator expressions.

Anyways, this article is about actively breaking systems like some kind of protocol terrorist in order to achieve an outcome at any cost, if it was merely along the lines of "CRLF considered harmful in new protocols" I'd have nothing to say.

Re: CRLF is obsolete and should be abolished

#216

Earlier quoted context omitted.

Why would you want that? All Unix text processing tools assume that every line in a text file ends in a newline. Otherwise, it's not a text file. There's no such thing as a "trailing newline," there is only a line-terminating newline. I've yet to hear a convincing argument why the last line should be an exception to that extremely long-standing and well understood convention.

> There's no such thing as a "trailing newline," there is only a line-terminating newline. Is "line-terminating newline" a controlled / established term I'm unfamiliar with or am I right to hold deep contempt against you? Because "trailing newline", contrary to what you claim, is 100% established terminology (in programming anyways), so I'd most definitely consider it "existing", and I find it actively puzzling that…

A trailing newline to me is "\n\n" at the end of a file, i.e. a superfluous empty line. That doesn't seem to be what the root comment is referring to, though?

Re: CRLF is obsolete and should be abolished

#217
post #56

Earlier quoted context omitted.

We're talking about servers and clients here. The best way to ensure things work is to adhere to an established protocol. Aside from saving a few bytes, there doesn't seem to be any good reason to deviate.

I'm saying the consistency that Filippo says our security depends on doesn't really seem to exist in the world, which hurts the persuasiveness of that particular argument in favor of consistency.

Security also doesn't exist as much as we'd like it to, which doesn't excuse making it exist even less.

Re: CRLF is obsolete and should be abolished

#218
post #108
post #23

Earlier quoted context omitted.

Not sure whether this changes anything about your critique, but note that the IBM 2741 terminal embedded a Selectric typewriter: > Selectric-based mechanisms were also widely used as terminals for computers, replacing both Teletypes and older typebar-based output devices. One popular example was the IBM 2741 terminal https://en.wikipedia.org/wiki/IBM_Selectric

Well, it says right there, the 2741 replaced Teletypes. It wasn't a Teletype. (Not sure I'd call this a "major gaffe", though!)

Not a capital-T Teletype but it seems like it was widely used as a teleprinter and had similar mechanical constraints/requirements. The post does touch on this language ambiguity:

> Teletypes (technically "teleprinters" - "teletype" was just the most popular brand name)

Re: CRLF is obsolete and should be abolished

#219

> various protocols (HTTP, SMTP, CSV) still "require" CRLF at the end of each line What would be the benefit to updating legacy protocols to just use NL? You save a handful of bits at the expense of a lot of potential bugs. HTTP/1(.1) is mostly replaced by HTTP/2 and later by now anyway. Sure, it makes sense not to require CRLF with any new protocols, but it doesn't seem worth updating legacy things. > Even if an est…

Not disagreeing with you, but implementation diverges from spec a lot anyway.

I've had to write decoders for things like HTTP, SMTP, SIP (VoIP), and there's so many edge cases and undocumented behavior from different implementations that you have to still support.

I find that it affects text based protocols, a lot more than binary protocols. Like TLS, or RTP, to stick with the examples above, have much less divergence and are much less forgiving to broken (according to spec) implementations.

Re: CRLF is obsolete and should be abolished

#220

Earlier quoted context omitted.

> There is no such character as NL ... More specifically the Unicode control character U+000a is, in the Unicode standard , named both LF and NL (and that comes from ASCII but in ASCII I think 0x0a was only called LF). It literally has both names in Unicode: but LINEFEED is written in uppercase while newline is written in lowercase (not kidding you). You can all see for yourself that U+000a has both names (and eol to…

Try the cat example again with your tty in raw mode instead of cooked mode. (stty raw) Note that your job control characters will no longer function, so you will need to kill the cat command from a different terminal, then type: stty sane (or stty cooked) to restore your terminal to "normal" operation. You will then see the 0d hex carriage return characters in the /tmp/anonymousiam file, and no 0a hex linefeed charac…

What bytes your terminal sends to communicate keys pressed and what is used in a text file to communicate the end of a line are not the same thing. "\eE" (0x1b 0x45) can be a terminal newline too, after all. Or try pressing Alt+Enter.
Post reply on HN