problem using Carriage Returns

[Meg]

let's say i'm writing a program that does the following:

1. open two text files, one as INPUT and one as OUTPUT
2. reads in lines from the INPUT file and writes them to the OUTPUT file
3. closes both files

when the program is done I want to have made an exact copy of the input file.

I'm running into problems at the end of lines:

Code:

Hello my name is Megan.

...becomes...

Code:

Hello my name is Megan.

However,

Code:

Hello my nam
e is Megan.

...becomes...

Code:

Hello my nam%e is Megan.

it's not really a percent sign, it's like a musical note or something. It's CHR$(13) as seen by the EDIT program.

Any suggestions?

*peace*

Meg.

btw, I know I can just SHELL and copy the file. That doesn't help I'm just too lazy to go into the details of the program unless I have to.

[Meg]

I should mention that I have set the tilde as being the break marker.

So the input file might look like this:

Code:

This is a test of the emergency broadcast system.~
Had this been a re
al emergency, the scream you've just hear
d would have been followed by many more just
like it.~

I want to be able to output this exactly like that to a text file, tildes, formatting, and everything.

The tildes just mean to me "this is the end of a block of information."

I'd like to be able to take in one block of information and print it to the screen, carriage returns, tildes and all.

Does this make sense?

*peace*

Meg.

[Glenn]

the file you're initially reading from has only ascii 13 characters at the end of each line and not ascii 13/10 pairs?

[Meg]

part of the problem is that i'm not sure how to read in whatever is at the end of the line.

if i

Code:

LINE INPUT #1, text$

or

Code:

INPUT #1, text$

then I don't know how I can see what's at the end of the line 'cause it doesn't seem to put it at the end of text$

if I add CHR$(13) to the end of text$:

Code:

text$ = text$ + CHR$(13)

and then output it:

Code:

OUTPUT #2, text$

the file sizes are different, and if i edit the output file in a text editor, i get that funky music note thingy.

*peace*

Meg.

[Glenn]

and read one byte at a time. Whenever the byte is 13, the next byte should be 10. (Writing the string "whatever" + CHR$(13), for example, could produce the kind of problem you're having.) Also, if you read the file one byte at a time, look for ascii 10 characters without an ascii 13 before them. (That's how UNIX text files have their lines terminated.)

[Mango]

let's say i'm writing a program that does the following:

1. open two text files, one as INPUT and one as OUTPUT
2. reads in lines from the INPUT file and writes them to the OUTPUT file
3. closes both files

when the program is done I want to have made an exact copy of the input file.

I'm running into problems at the end of lines:

Code:

Hello my name is Megan.

...becomes...

Code:

Hello my name is Megan.

However,

Code:

Hello my nam
e is Megan.

...becomes...

Code:

Hello my nam%e is Megan.

it's not really a percent sign, it's like a musical note or something. It's CHR$(13) as seen by the EDIT program.

Any suggestions?

*peace*

Meg.

btw, I know I can just SHELL and copy the file. That doesn't help I'm just too lazy to go into the details of the program unless I have to.

if you want an exact copy, you must use binary type...it has no formatting. Otherwise your output will screw up any bytes that happen to use enter, doublequote, or some other formatting character.

use long integers as your data type, then open as binary.
Get into a 4-byte variable
put into a 4-byte variable.

This will create an exact copy...

Actually, I believe this is not strictly true...do what I suggested until the closest 4-byte multiple of the file, then record the last 0-3 bytes one at a time using a single character as the datatype.

An example is the following...

Code:

DO
GET #1, , Fileword&
databyte& = passarray(counter) XOR Fileword&
PUT #2, , databyte&                             'get data from input file for keyb()

counter = counter + 1
IF counter > highpass THEN
  CALL passkeyshuffler(passarray&(), highpass, lowpass)
  counter = 1
END IF
counter2 = counter2 + 1
IF counter2 > 25000 THEN          'give a tic every 4*30 kb
z = z + 1
counter2 = 1
LOCATE 5, 18: PRINT "                                                           "
LOCATE 5, 18: PRINT INT(SEEK(1) / 1000); "kb out of "; INT(LOF(1) / 1000); "kb"
END IF
blockcounter& = blockcounter& + 1
LOOP WHILE blockcounter& < blocks&   'LOC(1) < LOF(1)

DIM Finalbytes AS STRING * 1

J$ = "j"

FOR t = 1 TO extrabytes

GET #1, , Finalbytes
finaldatA$ = CHR$(ASC(Finalbytes) XOR ASC(J$))
PUT #2, , finaldatA$

NEXT t

sorry if this is hard to follow...I just grabbed it from some code I wrote recently...the important thing to note is that the file is written using 4-byte datachunks...but there is code to deal with files whose length is not divisible by 4...

[Meg]

Thank you Glenn and Mango. I ended up finding a less efficient way to do it without using binary mode, but I'm glad you showed me how this works because it can be very useful for future projects!

*peace*

Meg.

[Moneo]

Some of the suggestions you're getting have merit but are too complicated.

First of all, we have to establish what your input file looks like. Text files or ASCII files in MS-DOS have a Carriage Return and a Line Feed (CRLF) at the end of every record, which are 0D OA in hex or 013 010 in decimal. If the editor or program which you used are not creating records in this manner, that's the root of your problem. When you do a LINE INPUT in QB, it will assume that a "line" or record ends in CRLF, that is, it will read until it encounters a CRLF or end-of-file.

By the way, always use LINE INPUT to read records from a text file.

You can preview what lines or records your program will see via a LINE INPUT by executing the following form the DOS prompt:
TYPE filename
The lines or records that appear on the screen are exactly what you program will receive via a LINE INPUT command.

If the input file is not your problem, let me know so we can go on to the next step.
*****

[Meg]

thank you for the feedback, but i've solved the problem already.

good info. I did not know that 13/10 ended the lines (i always assumed it was just 13)

*peace*

Meg.