what is these number of bytes in a file?

[jarychk]

The JB Helpfile shows a sample piece of code, which I am trying to learn from and the use.

I have a file, created through a J B program which is THIS:

11
7
1

Then this block of code should, what, tell the number of bytes in the file? But it seems to simple put the file contents all in a horizontal line, so not sure what is "bytes" and not sure how "number of bytes" is "1171".
open "programoptions.txt" for input as #1
 qtyBytes = lof(#1)
 for x = 1 to qtyBytes
   print input$(#1, 1) ;
 next x
 close #1

I hope to find if the file is either empty or if it has an expected count of values as its content; like if it has ANYTHING in it, it should have three values in it.

[jarychk]

I already believe a practical way to handle is is possible.

I changed the file contents to be simply this:

1
1
1

and after the loop but before "close", inserted PRINT lof(#1) which outputs the number 9.
Three single digit values in the file, and length of file is 9.

I do not fully understand but I may work with this.
Main idea is, in case the file does not have enough in it, create a default file, with certain default values.

[tenochtitlanuk]

Welcome to the world of files!

Files are simply a list of 8-bit numbers, each therefore between 0 and 255.

Text files represent the printable characters, coded as numbers from 32 to 255. Numbers between 0 and 31 are 'control' codes that mean something to a printer or display or program.

The control codes of most importance are CR ( carriage return) and LF (line feed). On the old mechanical teletypewriters they move the print head back to full left, and advance the paper one line.

So that a data file can show separation of one item from another we need a 'separator' control code. This is typically a TAB, a comma, a CR, a LF, or a CR+LF. CR+LF is characters number 13 ( 0D in hex) and 10 ( 0A in hex).

The image, created with a 'hex editor', shows that when you simply store your three numbers to a file, in order to know when one stops and the next number is intended, my computer has added CR+LF in between them. There are your extra bytes.

Unfortunately, the worlds of Microsoft, Linux and Mac disagree on which is the 'standard' separator. Files created/read on your OWN computer will give no trouble. But those from the 'other' worlds need converting.

[Rod]

When you print “1” to a file Liberty actually sends “1CrLF” three characters. As John explains the CrLf pair are control characters.

You can prevent this by print “1”; the ; stops Liberty adding the CrLf pair but then you have no line separator.

You can build the file in whatever format you wish but standard protocol adds CrLF and so three “1”s becomes 9 characters in the file.

[jarychk]

Rod (and @tenochitlanuk)
That lets the program creator make code to check for some quality of the file to be used. If such a file needs to contain three values, then each value giving three characters, or possibly four characters if the piece of the file is two digits.

I'll have to check again more carefully.
If the file contained the pieces 11, 7, and 1, then the length of the file should be 4+3+3=10; but when the computer program checks the quality of the particular file, and the file needs to contain three values, then the file is good if LOF greater or equal to 9; and bad if LOF less than 9. After checking the quality of the file, program can be coded to conduct proper actions.

[jarychk]

just one small question:
Which happens first when a new piece of data is put into a sequential file? The line feed or the carriage return? Is this important?

[plus]

Chr$(13) is enter key AKA CR or carriage return

then Chr$(10) is line feed key.


Also sometimes a Basic will insert an extra CR + LF at the end of the file, so if you get 2 extra bytes than expected, it's probably that.


b = b + ...

[jarychk]

(Quotes button is not present in your post; I will copy&paste part of...)

..., will insert an extra CR + LF at the end of the file, so if yo...

You did not say it distinctly but the answer might be guessed as, the carriage return happens first, and the line feed happens next.

Another thing I have trouble understanding is the exact meaning of "Carriage Return". When we use this for displaying text information, just using chr$(13) puts the continued display onto a fresh line starting at the left side. I cannot understand this to not be also Line Feed.

But no matter - I am making progress with an application in development currently.

[plus]

Yes chr$(13) is first and chr$(10) is 2nd or they are used singlely usu chr$(10) more than chr$(13) depends on file and system you are working with.

And they both will likely do the same thing singlely with PRINT statements.

Carriage return and line feed are from old, old, old printers that were more like type writers.
CR ends the line, ding! on the type writer
LF is grabbing that lever and manually shifting it left, meanwhile a physical gear rotates the roller so you start the next line.

They used these typewriter like devices for the first "Dummy Terminals" for main frame access INPUTs and OUTPUTs
inputs you type something
outputs the computer sends something back on the next line or so... some times pages and pages of stuff.
And you had to worry about reloading paper that was used like TP

b = b + ...

[Rod]

Yep, in the old days, fifty years ago, control characters moved the print position, Cr slung the head back to the start of the paper, Lf moved the paper up a line.

Nowadays it is entirely up to the software system displaying the text how these characters are interpreted. Some systems don’t even use two characters anymore. Mostly all systems will now start at the left edge and down a line if they encounter one or both of these characters in a file.

Fortunately we most often create our own files so it is easy to pick one protocol and stick with it.

[tsh73]

Hello jarych
I tnink if you need to make sure file contain three numbers you just go on and read these 3 numbers
You can check if file is ended (EOF) in process, so you have some number missing
And you can check range to see if number is valid
(like, reading "abs" as number produces no error but returns 0, But if 0 is out of range, you know that something is wrong.)
Play with this.
open "test.dat" for output as #1
print #1, 1
print #1, "abc"     'thing that reads as 0
'print #1, 2        'missing items it caught bu EOF(), no error happens
'print #1, 3
close #1

timer 300 , [nxt]
wait

[nxt]
timer 0


open "test.dat" for input as #2
k=0
while not(eof(#2)) and k<3  'fils in not ended, and we need only 3 numbers (extra will be ignored)
   k=k+1
   input #2, a(k)
wend
close #2

print "Have read ";k; " numbers"
print "only if you see 0 it could be something in a file that could not convert to number"
for i = 1 to k
   print a(i)
next




[plus]

If LOF(#1) = 0 then
Print "The file is empty"
else
' load file
endf if

b = b + ...