Re: [Monotone-devel] "monotone cat file" not binary save?

[Hendrik Boom]

On Wed, Sep 07, 2005 at 03:00:30AM +0200, Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Tue, 6 Sep 2005 14:27:23 -0700, Nathaniel 
> Smith <address@hidden> said:
> 
> njs> It's definitely not an intentional feature of 'cat'.  However,
> njs> it's possible that it's some unavaoidable win32 bogosity, like
> njs> stdout being provided as a text-mode descriptor that is
> njs> inherently lossy or something...
> 
> As most other operating systems that have a line endine sequence other
> than NL, I think Windows C library *correctly* does NL->CRNL
> conversion on stdout unless you somehow explicitely tell it that the
> output should remain unconverted.

I believe you mean LF instead of NL.

Historical note:

LF -- LineFeed - is ASCII character
0x0a, (Unicode u000a), and has traditionally meant moving vertically
downward to the next line, preserving horizontal position.  CR meant
carriage return, which was to move to the beginning of the same line.
So on the old TTYs which were still prevalent on the 60's (and were
probably much older), starting a new line was CR-LF.  The CR was first
because it took time to move teh carriage all that much and the LF gave
the TTY time to finish returning the carriage.

It was Unix, and C, I believe, that started the perversion of using
LF to mean CR-LF.  The relevant standard of the time specified that
so simplify keyboarding, input routines could interpret a single keystroke
as CR-LF.  But it was the more natural CR that was to be the single
keystroke, not LF.

There *has* been a NextLine character defined in the course of time,
but I've never seen it used.  It's 0x85, Unicode u0085, and it's name is
Next Line, abbreviated NEL.

End of historical note.

I usually read my text files in binary, and recognise either CR of LF as
meaning end-of-line, and ignore a CR after a LF of a LF after a CR.

Output is always a platform-dependent hassle, however.

-- hendrik