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.

"Beancounter" <jonescpa@gmail.com> skrev i meddelandet 
news:b9395c52-f604-4c9d-9ce4-f3e255ca7a45@d37g2000yqm.googlegroups.com...
>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" <computer_hero@coldmail.com> schrieb im Newsbeitrag 
news:hujbe3$bk8$1@news.eternal-september.org...
>
> 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.

Henning wrote:
....

> 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.
....

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.

--

Beancounter wrote:
> 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
>

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"

"Henning" <computer_hero@coldmail.com> wrote:

>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?

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

sfdavidkaye2@yahoo.com (David Kaye) wrote:

>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.  

David Kaye wrote:
> "Henning" <computer_hero@coldmail.com> wrote:
> 
>> 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?
> 
> The CRLF format is peculiar to DOS and Windows. In the rest of the
> world it's just CR.
> 

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... :)

--

"David Kaye" <sfdavidkaye2@yahoo.com> wrote in message 
news:hujj6n$ac1$2@news.eternal-september.org...

>>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?
>
> The CRLF format is peculiar to DOS and Windows.

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.

> In the rest of the world it's just CR.

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! 

On 07/06/2010 21:01, David Kaye wrote:
> "Henning"<computer_hero@coldmail.com>  wrote:
>
>> 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?
>
> The CRLF format is peculiar to DOS and Windows.  In the rest of the world it's
> just CR.

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.

-- 
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

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

"Jeff Johnson" <i.get@enough.spam> wrote in message 
news:hujqu9$v41$1@news.eternal-september.org...
> "David Kaye" <sfdavidkaye2@yahoo.com> wrote in message
>> The CRLF format is peculiar to DOS and Windows.
>
> 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.

.. . . 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 Williams" <Mike@WhiskeyAndCoke.com> schrieb im Newsbeitrag 
news:O$rSzguBLHA.980@TK2MSFTNGP04.phx.gbl...
> "Jeff Johnson" <i.get@enough.spam> wrote in message 
> news:hujqu9$v41$1@news.eternal-september.org...
>> "David Kaye" <sfdavidkaye2@yahoo.com> wrote in message
>>> The CRLF format is peculiar to DOS and Windows.
>>
>> 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.
>
> . . . 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. 

"Helmut Meukel" <Helmut_Meukel@NoProvider.de> wrote in message 
news:hul9re$4o7$1@news.eternal-september.org...

> Mike, I can't remember the sequence my old manual
> typewriter performed the tasks, it  probably differed
> from manufacturer to manufacturer

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).

> 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.

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"
<Mike@WhiskeyAndCoke.com> wrote:

>"Jeff Johnson" <i.get@enough.spam> wrote in message 
>news:hujqu9$v41$1@news.eternal-september.org...
>> "David Kaye" <sfdavidkaye2@yahoo.com> wrote in message
>>> The CRLF format is peculiar to DOS and Windows.
>>
>> 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.
>
>. . . who themselves inherited it from the old fashioned manual typewriter, 
>although in the case of the manual typewriter it was LF followed by CR.
>

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.

On Jun 8, 7:22=A0am, "Mike Williams" <M...@WhiskeyAndCoke.com> wrote:
> "Helmut Meukel" <Helmut_Meu...@NoProvider.de> wrote in message
>
>
> > I however used/programmed a typewriter in the
> > mid-seventies and while you could first punch =A0LF
> > 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.
>
> Ah, but that's not what I would call a manual typewriter. It's one of tho=
se
> new fangled beasts with the fancy electric motors! And of course it
> certainly does not pre-date the manual typewriters that I am talking abou=
t
> ;-)
>
> Mike

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

"ralph" <nt_consulting64@yahoo.net> wrote in message 
news:4n6t061c8sgjaesugfq6leh52gft2l26ch@4ax.com...
> On Tue, 8 Jun 2010 09:54:26 +0100, "Mike Williams"
> <Mike@WhiskeyAndCoke.com> wrote:
>>although in the case of the manual typewriter
>> it was LF followed by CR.
>
> It will perhaps make more sense if you appreciate that
> 'Line Printing" came from Telegraphy/Teletype devices,
> not 'manual typewriters'.

What do you mean by, "it will perhaps make more sense"? It already makes 
sense to me. Always has done. As I stated, and as you can see in the above 
extract, "in the case of the manual typewriter it was LF followed by CR".  I 
don't care where the phrase "Line Printing" came from (although I do know 
where it came from). I never mentioned that phrase since it was not relevant 
to what I was saying. I simply stated the truth, and that is the fact that 
on the old fashioned manual typewriter it was almost universally "line feed 
before carriage return". There have been a few "odd ball" machines, but in 
general the operator of almost all manual typewriters typed characters one 
by one and as she did so the carriage slowly moved to the left, until the 
desired end of the line was reached. Then the operator almost invariably 
performed a "line feed" to roll the paper down to the next line, followed by 
a carriage return to return the carriage back to the right side of the 
machine in order to start typing the next line, and those two operations 
were carried out in that specific order by the same one lever movement. And 
of course old fashioned manual typewriters, which as I have said almost 
invariably used line feed followed by carriage return, long predated your 
telegraphy and teletype / teleprinter device (which, incidentally, we had 
great fun with many years ago when I was in the Army, sending images of the 
Queen and other unsavoury characters as Ascii :-)

Mike