0x0a, one of whose names is NL. This is well-defined. This is not a question about ASCII; it is a question about how some unspecified system represents linebreaks - about how that system uses ASCII, perhaps. Worse, on many systems the answer differs depending what point you measure at. On most Unix variants, for example, it's 0x0a when measured in files or in C strings, but 0x0d 0x0a when measured on hardware serial lines. It's only one character; that much is well-specified (well, assuming your '\n' was supposed to be C). What the numerical value of that character is is not well-defined without reference to a particular system (though 0x0a is by far the commonest, probably because it's ASCII NL). Then in what sense are those choices "wrong"? "the mail program"? There were at least..um, let's check headers..6 pieces of software that could reasonably be called "mail program"s involved in getting the message from Hank to any list receiver's system, possibly excepting the small (maybe empty) set of people who actually read list mail on dewey.classiccmp.org. There's at least one additional piece of software involved (displaying the message) and possibly more. By definition, in the SMTP transaction, the line breaks are 0x0d 0x0a octet pairs (and 0x0d and 0x0a octets do not occur in any other context than 0x0d-0x0a line-break pairs..unless, of course, the sending SMTP code is broken). Of course, there is a lot of broken SMTP code out there. Looking at headers makes me think Hank's mail was actually sent through Hotmail, which means it's almost certain the sending SMTP code was broken (though not necessarily in this way). However, as it arrived at my system, it apepars to have been fine in this regard, so I see no reason to think line-break botches elsewhere than between the list and Ethan are behind this. I'm mystified as to what provoked the behaviour Ethan saw, since he says it's just Hank's mail, and as far as I can tell Hank's mail is fine after passing through the list. Ethan, did Hank send you an off-list copy, and you replied to that one, maybe? It's the most plausible theory I see offhand. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

der Mouse wrote: That's interesting. I see the same behaviour as Ethan does (Thunderbird 1.5 / Linux here) for Henk's replies to the list (but not his original messages). There's at least one other listmember for which I see the same behaviour, too, but names elude me right now. I *think* I raised it with one such person before, and there was something unusual about their setup - but I might be confusing this with the "why do some people include unedited text, separator, and then their text in their replies" thread from a while ago... cheers Jules

Hm, I was under the impression that 0x0a had two names, LF (line feed) and NL (newline), and that it was up to each sender and receiver using the code to decide which meaning they'd use. This impression dates back long enough that I no longer have any idea where I got it, but it must ahve been a source authoritative-seeming enough for me to have believd it at the time. Someday I should go look up the real X3.4.... /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Hi, der Mouse said: It's the other one: 0x0d... CR Control M 13 0D 0001101 Carriage Return A format effector that controls the movement of the printing position to the first printing position on the same printing line. In some cases the CR will incorporate an automatic line feed (LF) as either a default or an option. This feature, called New Line (NL), is used to make computer keyboards more like those of typewriters. -- Cheers, Stan Barr stanb at dial.pipex.com The future was never like this!

On Sat, 29 Dec 2007, der Mouse wrote: There's the bit I was looking for. Hotmail recently became "Windows Live". In their most recent "upgrade", I noticed it doing this to messages I reply to. It even drops the line breaks from my *signature*, despite being a Hotmail signature that's been defined for ages. Basically, Microsoft broke Hotmail recently. Users have to be careful. -- roger ivie rivie at ridgenet.net

OK, I have seen my own reply ... top-posting is no different. The text at the bottom is also stripped of all control characters it seems. I am running Windows XP SP2 and use "Windows Live Hotmail". For this experiment, I concatenated the original quoted text at the top, and created the separated lines by hitting "Enter". It is a bit of labour, but if that makes the quoted text look good, it is better to do it myself, than giving many people a hard time reading that. It also helps in trimming a reply :-) I hope the quoted text now has CR's. One repeat, to "add some information" in this message: I have written the LA180 page (partly) and put it on my site. Go to www.pdp-11.nl and navigate to: peripherals -> comm -> printers -> LA180 Henk, PA8PDP (again keeping fingers crossed...)

"It depends" - which was really my point. It could send 0x58 0x0a, or it could send 0x58 0x0a 0x0d, or possibly even other things under more unusual circumstances. Even serial lines can on most systems be put into a mode wherein they're content-blind octet streams, in which case mapping between '\n' and CRLF doesn't happen. Of course, the printier may well be a parallel instead of serial interface, in which case it's even more of a crapshoot what you get. Parallel interfaces usually are treated differently from serial interfaces, and mapping '\n' to CRLF is one of the things that plausibly may differ. But it still depends on where you measure. It's plausible, for example, that it's two octets at the syscall interface but three at the hardware interface, each of which is a reasonable interpretation of "actually send to the printer" in an appropriate context. See above - usually either two or three, depending on whether '\n'->CRLF mapping is being done. Within the context of their systems? Only that it hampers interoperability, both mechanized and human, but that's not enough for me to call it "wrong" in isolation from a context. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

It was thus said that the Great der Mouse once stated: If you run the following bit of C code under MS-DOS (or Windows): #include <stdio.h> #include <stdlib.h> int main(int argc,char *argv[]) { FILE *fp; int c; if (argv == 1) fp = stdin; else fp = fopen(argv[1],"r"); if (fp == NULL) { perror(argv[1]); return(EXIT_FAILURE); } while((c = getc(fp)) != EOF) { if (c == '\n') printf("new line\n"); else if (c == 0x0D) printf("carriage return\n"); } return(EXIT_SUCCESS); } All you will see is repetition of "new line"----you won't see any "carriage return" at all. That's because the Standard C Library is sucking up the carriage returns. Upon printing a '\n', the Standard C Library is silently adding carriage returns. Change the "r" in the fopen() call to "rb" and then you'll start seeing carriage returns. -spc (Gah! Why do I remember this horrible MS-DOS crap?)

On Sat, 29 Dec 2007, Roy J. Tellason wrote: that makes sense. I have run into LF CR in files, but haven't gotten around to tracking down what system created them. THAT would give LF CR on some systems! Many companies went that route. Some Tandy compatible printers had "smart auto linefeed" - a line feed would be added to a CR IFF there was not a LF following the CR. That worked well except for the LF CR case. -- Grumpy Ol' Fred cisin at xenosoft.com

It was thus said that the Great Fred Cisin once stated: What I've heard---there is no one character that returns the carriage to the start of the line (CR) and advances down one line (LF). MS-DOS seems to think both are required, whereas Unix went with one (LF) and add both if required in the driver code. The older versions of Mac OS (prior to being Unix under the hood) used CR. And while I wrote code to handle CR, LF, CRLF, LFCR, I never did see LFCR in the wild. Another recurring issue for ASCII: what is baskspace supposed to do? I'm used to systems that use $08 [1] to move the cursor left one column and overwrite the character there with a space. But Linux (maybe because Linus was secretly a DEChead?) decided that $7F would move the cursor left one column and overwrite the character there with a space, but X Windows (which I use on Linux) seems to want to use $08 for that. Grrrrr ... If you read up on the SMTP specification [2], they require the use of CRLF to terminate each line, and it's up to the receiving side to add/remove/translate the line ending characters as appropriate. There is some verbiage in the older SMTP RFC [3] dealing with bare CRs in header lines (treat it as whitespace, but preserve); I'm not sure if the that has been carried over to the current standard [2]. -spc (Who now gets to deal with UTF-8 pages served up as ISO-8859-1 or worse, Windows-1251 ... ) [1] Sorry, I'm old school---hex numbers are preceeded with a currency sign. [2] RFC-2821 [3] RFC-821

I just noticed an occurrence of LFCR "in the wild". I run a number of NetBSD machines (most of which are actually on-topic, though there are a few peecees). Amonjg them is a "shark", a DEC DNARD. I have this set up with serial console, and I happened to notice, today, when looking at a snapshot of output from the serial console, that it uses LFCR line breaks, on the serial line, during device autoconfig! (Once the kernel is up, it starts using CRLF.) I haven't dug into the NetBSD kernel code to see where these LFCRs are coming from. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B