Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tellab5!vpnet!dattier
From: dattier@vpnet.chi.il.us (David W. Tamkin)
Newsgroups: comp.sys.cbm
Subject: Re: Reading SEQ files
Message-ID: <1991Mar06.005908.19145@vpnet.chi.il.us>
Date: 6 Mar 91 00:59:08 GMT
References: <1991Mar02.032753.23899@ddsw1.MCS.COM> <39733@cup.portal.com> <1991Mar4.132134.27485@cs.dal.ca>
Organization: VPnet Public Access Unix, Villa Park, Illinois  60181-2206
Lines: 41

digdon@ug.cs.dal.ca (Mike Digdon) wrote in <1991Mar4.132134.27485@cs.dal.ca>:

| 10 open4,4,7:open2,8,2,"filename,s,r"
| 20 get#2,a$:ifst<>0thenclose2:close4:end
| 30 print#4,a$;:printa$;:goto20

| And it runs with no problems everytime, and it always stops when it is
| supposed to (IE: at the end of the text file)

Nope.  ST goes nonzero when you read the last character in the file.  The
code you posted would never print the last character.  If the last character
is a carriage return, BASIC will stick one in before "ready." (I think), so
maybe you haven't noticed the problem.  You might get "ready." on the next
line after your text without a blank line in between, which wouldn't bother
you.  But if there is something odd about the text file and the last
character is not a CR, you won't see it printed.

Earlier Commodore systems (I don't know whether it was the drive's doing or
the computer's doing) did give a zero value for ST as long as a character was
read and went nonzero only after you tried to read past the end of the file,
and for them Mike Digdon's code is correct.

You can also change "ifst<>0" [which could have been shortened to "ifst" but
that's another matter entirely] to "ifst=66" or "if2andst" [do not use
"ifstand2" because BASIC will read the TAN keyword before it recognizes the
ST reserved variable; "ifst and2" will work] in line 20.  Then you'll get the
last character as well.  ST goes to 64 when you read the last character and
to 66 when you try to read past it.

And of course, input# is faster since there are fewer calls to the BASIC
interpreter, fewer loops, and fewer serial accesses, but if there is a comma,
a colon, or a linefeed in the line, what gets read won't get written.

For a BBS I once helped run, we used to add 128 to all risky characters in
bulletin files so that INPUT# could read and preserve whole lines.  The
modem-output routines stripped the high bits, so the callers saw normal text.

David Tamkin  PO Box 7002  Des Plaines IL  60018-7002  dattier@vpnet.chi.il.us
GEnie:D.W.TAMKIN  CIS:73720,1570  MCIMail:426-1818  708 518 6769  312 693 0591

"Parker Lewis Can't Lose" mailing list:   write flamingo-request@ddsw1.mcs.com