I had this problem, and saw others had it as well; I just wanted to
post my solution which turned out to be simple (in code).

For years I've been parsing a csv download file using the standard VBA
line input function.  Well, the download file is still a csv, but
longer has CRLF, just LF.  As a result,  the line input function now
reads the entire file at once, instead of line by line.  To solve it,
I just used the replace function:

sub mproFileLineInput.

Open "c:\NeededFile.csv" For Input As #1     'Open download file

Line Input #1, txtline    'read line input, which reads entire file
because no CR Chr(13), just LF Chr(10)
NewText=Replace(txtline, Chr(10), vbCrLf)  'Find all Chr(10) LF and
replace with CRLR

Close #1

Open "c:\NeededFile.csv" For output As #1  'Open file again, but for
output this time
Print #1, NewTxtLine  'use print function to write contents, but with
LF replaced by CRLF
Close #1

End sub

Hope it helps anyone with same problem.

Just read here or there that someone deliberately saved files in that
format. For me it's a big why?? to save some CR's? Or is it to ease for
mac'ers to read the files?

Your example shows the outcome of same row-delimiter-change.

/Henning

Henning,

a LF without a CR is UNIX, Linux, AmigaOS and now Mac -
since Mac OS X.
Until Mac OS version 9 the Mac was usung a single CR without
a LF. Same for the Apple II.
CR+LF is Windows, DOS, OS/2, CP/M, Atari TOS.

For the old teletypes you needed both CR + LF.
In the mid-seventies I saw a program using a teletype as "printer".
They used multiple CR without a LF to write columns.
With a teletype you had to send first the CR (carriage return) then
the LF (line feed) due to the latency time of the mechanical equipment.
If you did it the other way, the first character of the new line was
printed somewhere to the right, not in the leftmost position.

Helmut.

...

...

It's Unix-ish; I commented on the same posting not long ago that it's
not wise to do so for Windows platforms in that there is much that doing
so may unexpectedly break when the files are used for anything other
than an app that knows to expect it.

--

FWIW, if you need to do this often or quickly, there's a faster way
(actually, a few faster ways).

The least faster, but most straightforward way, is (AIR CODE):

  Open "c:\NeededFile.csv" For Binary As #1

  Buf$ = String$(LOF(1), 0)
  Get 1,,Buf$
  Buf$ = Replace$(Buf$, vbLf, vbCr) ' NOT vbCrLf
  Put 1,1,Buf$
  Close #1

This works because while VB won't deal with files having only a LF
delimiter, it does just fine with only a CR delimiter (VB essentially
ignores LFs). It's faster because the string (and the file) doesn't
need to expand.

More speed if you avoid strings (and Unicode):

  Dim Idx As Long
  Dim Buf() As Byte

  Open "c:\NeededFile.csv" For Binary As #1

  Idx = LOF(0)
  ReDim Buf(1 To Idx) As Byte
  Get 1,,Buf()
  For Idx = 1 To Idx
    If Buf(Idx) = 10 Then
      Buf(Idx) = 13
    End If
  Next
  Put 1,1,Buf()
  Close #1

Of course any method, including the one you propose, should only be
used if you know that the file contains only LF delimiters.

--
   Jim Mack
   Twisted tees at http://www.cafepress.com/2050inc
   "We sew confusion"

The CRLF format is peculiar to DOS and Windows.  In the rest of the world it's
just CR.  

I got it backwards.  It's LF.  

For suitable definitions of "rest" and time frame, anyway... :)

DEC RT-11 was at least one crlf that I recall.

CDC NOS used double 6-bit 0's (after 60-bit words).

Many other things that now seem oddities... :)

--

In the sense of they're the only surviving major OSes that use that
convention. They certainly didn't invent it just to be different; they
inherited it from their predecessors.

You've already corrected yourself on that one, but realize that "the rest of
the world" isn't as big as it might sound when you consider just how much of
the world is DOS and Windows!

Erm, the vast majority of (text based) network protocols specify a CRLF
line ending.
SMTP, POP, IMAP, HTTP (and derivatives), NNTP, Email content, etc. all
use CRLF.

--

i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

. . . who themselves inherited it from the old fashioned manual typewriter,
although in the case of the manual typewriter it was LF followed by CR.

Mike

Mike,

I can't remember the sequence my old manual typewriter performed the tasks,
it  probably differed from manufacturer to manufacturer, and I never used an
electrical typewriter. I however used/programmed a typewriter in the
mid-seventies and while you could first punch  LF followed by CR it was
*not* advisable to do so. The first character on the new line wouldn't be in
the leftmost position due to the latency time of the mechanical equipment.
In other words, the next character was printed while the print head was still
moving to the left side.
They had deliberately shortened the delay after a CR to increase overall
print speed. If you used CR-LF this didn't matter, the line feed could
happen while the print head was still moving.

Helmut.

As far as I recall it was the same for every manufacturer, and with good
reason. Both the line feed (the rotation of the roller around which the
paper was fed) and the carriage return (the actual sliding of the entire
carriage from left to right) were performed with just one lever. The user
moved the lever and the first part of the lever movement caused the
mechanism to first rotate the roller (line feed) and whilst it was doing
that it did not meet with sufficent mechanical resistance to actually begin
to move the carriage along. It was only after it has rotated the roller by
the equivalent of one line (using the first small amount of the user's lever
movement) that the lever came up against the mechanical roller stop, and the
rest of the user's continued movement of the lever then caused to carriage
to move along. This enabled the user to perform both a line feed and a
carriage return (an often required action) with one single movement of the
lever, and it also allowed the user to perform just a line feed without a
carriage return (another often required action) simply by moving the same
lever just a short amount, without continuing to move it once the "begin to
move the carriage" resistance was felt (for line spacing between paragraphs
etc and whenever else it was required to position the next line a number of
lines below the preceeding one).

Ah, but that's not what I would call a manual typewriter. It's one of those
new fangled beasts with the fancy electric motors! And of course it
certainly does not pre-date the manual typewriters that I am talking about
;-)

Mike

On Tue, 8 Jun 2010 09:54:26 +0100, "Mike Williams"

It will perhaps make more sense if you appreciate that 'Line Printing"
came from Telegraphy/Teletype devices, not 'manual typewriters'.

Various conventions came about to abstract the notion of a "New Line".
Many of these conventions overloaded a specific value in order to save
clicks/space. So whenever one takes a closer look they have to
consider the context under which a "NewLine" is defined or expected.

For example, the reason Lf/Cr may occasionally fail under a particular
scheme - is because it is not recognized as a "NewLine" while Cr/Lf is
- even though literal control defined by each in whatever order
produces the same result.

You're probably referring to a good old-fashioned Underwood
typewriter!  I used to use one of those!  Young kids these days and
their new-fangled electricity!

Chris