vim & CRLF

[L. V. Lammert]

Need a physical CRLF as a line terminator for sending test data, .. so I
changed filetype to dos in vim. Unfortunately, when switching TO dos
filetype, vim appends 0a0d, not 0d0a!

Would anyone know how to actually get CRLF as a line terminator in vim?

Thanks!

Lee

[Jay Truesdale]

Here is how to change EOL to CRLF.

:%s/$/Ctrl-VCtrl-LCtrl-VCtrl-M/

Global substitution, change EOL to the two control characters. Ctrl-V Ctrl-J will insert a line feed, Ctrl-V Ctrl-M inserts a CR.

​Make sure you have the file backed up!​

[L. V. Lammert]

On Thu, 30 Mar 2017, Jay Truesdale wrote:

> Here is how to change EOL to CRLF.
>
> :%s/$/Ctrl-VCtrl-LCtrl-VCtrl-M/
>
> Global substitution, change EOL to the two control characters. Ctrl-V
> Ctrl-J will insert a line feed, Ctrl-V Ctrl-M inserts a CR.
>

Interestingly enough, .. 0a0d *is* the correct sequence - I always
thought it was actually 0d0a!! I created some test files in Notepad, and
they were also 0a0d, ... so the vim filetype is correct.

Thanks!

Lee

[The King Family]

A couple of things to remember.

Standards matter. If the standard says order matters, then order matters.

IETF RFC 2608, and RFC 2616.

2.2 Basic rules

The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986.

...

CR = <US-ASCII CR, carriage return (13)>

LF = <US-ASCII LF, linefeed (10)>

...

HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications).

- - - - -

In layman's terms, the HTTP protocol standard states you MUST use \r\n as the line terminator. This remains the case in the current RFC 7230 for HTTP.

CR = (13) = 0x0D

LF = (10) = 0x0A.

Mnemonic: "ReturN" = R before N.

0D0A = \r\n = CR,LF = carriage Return, liNe feed.

Now if your context isn't HTTP and you're really talking about the OS-dependent "Line Terminator" concept, then what you really want is to define the file/data format terminator in an OS-independent way, as HTTP did, or to explicitly embrace it and use your programming language native construct for the OS line terminator so you don't have to worry about it.

In any .NET language, it is Environment.NewLine.

In Java7 and beyond, it is System.lineSeparator().

In Java6 and below, it is System.getProperty("line.separator").

And in Perl, it is $/ (input record separator) and $\ (output record separator). It has distinct semantics for reads and writes, unlike other, lesser languages.

In Awk, it is the RS varable.

In Vim, it would be:  :e ++ff=dos

The global option is :set ffs=dos,unix

The reason for the "CR before LF" is steeped in the history of typewriters and dot-matrix printers:

A reason for putting the line feed after the carriage return is that reduces the total amount of time required -- while the head is returning to the left edge of the paper, the platen can index one line. The longer operation starts first, so the whole operation completes in the time it takes the longer operation to execute.

See? Multitasking and parallel processing are just so last century.

Just because you didn't pay tuition doesn't mean you didn't get schooled.

Mike808/

[Don Ellis]

"Reduces the total amount of time required"

My first project on a PC was setting up an IMSAI (one of the first PC clones -- of an Altair) to measure amputee stump dimensions on a VA supported program at TIRR (Hospital in Houston). Terminal/storage was an ASR33. Initially, the system was set up to do LF+CR for newline (I had been hearing/using the term CRLF for years at this time).

Each operation (CR, LF) takes the same amount of time. If the LF takes place first, the print head can start delivering characters to the page before it has returned to the left side of the page. If CR takes place first, the print head has the time of the CR operation plus the time of the LF operation before characters can start printing. With the LFCR combination, up to 2 or three characters can be scattered across the page from right to left, each slightly lower than the previous one.

So, sending characters in CRLF order allows enough time for the print head to get in position, while LFCR does not. Yes, a buffer would be nice, but then you wouldn't be using an ASR33, would you? I can imagine that the programmers had used a different terminal, maybe a CRT, where the order doesn't matter.

Upgrading from ASR33 to an audio tape storage method made boot loading much faster, first because it's a faster medium, second because the loader is much shorter and can be toggled in from the front panel much more quickly. We were beginning to talk about burning it to ROM when I left the lab to become and independent consultant. Upgrading RAM from 16K to 48K made a tremendous difference too; we could actually load and run assembler programs, and I started experimenting with BASIC.

This was a couple of years before I moved from Houston to St Louis in 1979. I bought a personal SBC (Single Board Computer) about that time. Much more advanced; had a hex keypad for a front panel instead of toggle switches. There were several other SBCs that my friends & I experimented with about that time, each more advanced or more accessible than the previous one.

On Thu, Mar 30, 2017 at 5:42 PM The King Family <michael.ev...@gmail.com> wrote:

A couple of things to remember.

Standards matter. If the standard says order matters, then order matters.

...

[Steven Lembark]

What about:

s/$/^V^M/

--
Steven Lembark 1505 National Ave
Workhorse Computing Rockford, IL 61103
lem...@wrkhors.com +1 888 359 3508

[L. V. Lammert]

On Wed, 5 Apr 2017, Steven Lembark wrote:

> What about:
>
> s/$/^V^M/
>
Actually, hex mode was more useful:

:%!xxd

Thanks!

Lee