LINE INPUT #, documentation.

Forum for discussion about the documentation project.
Post Reply
sigmason
Posts: 22
Joined: Sep 21, 2006 2:18

LINE INPUT #, documentation.

Post by sigmason »

I've been writing a configuration file parser for the Windows XP command line using FreeBASIC.

I think I've found an error in your documentation.
Actually, I'm pretty sure it was also the same error in the old QB45
documentation as well.

The terminating character for a LINE INPUT # is either a carriage return or
a carriage return and line feed pair (in that order.)

In the documentation for the LINE INPUT # command it shows as
either a line feed or a carriage return and line feed.

The only standalone character that will actually stop LINE INPUT # is
carriage return, I checked it.

I noticed this while trying to make it so that the rather lengthy interactive
help in my standalone executable could be redirected to a file via a command line >.

Just letting you know,
Sigmason
sir_mud
Posts: 1401
Joined: Jul 29, 2006 3:00
Location: US
Contact:

Re: LINE INPUT #, documentation.

Post by sir_mud »

You have a bit of sample code to test it? If so I'll test it on linux too.
sigmason
Posts: 22
Joined: Sep 21, 2006 2:18

Re: LINE INPUT #, documentation.

Post by sigmason »

I was wrong about this, sorry.
The LINE INPUT # documentation is actually correct.
(I checked it's not right in my copy of the MS QB45 manual, I have it
highlighted in there from WAY back.)

The reason I see this error is because the ASCII character table in the
documentation is wrong.

Please refer to:
http://en.wikipedia.org/wiki/Ascii#ASCI ... characters

The line feed is decimal 10 and the carriage return is 13.

This is the line in my version of the FreeBASIC DOS help:

"Many of the standard ASCII characters cannot be PRINTed in FB, because the console interprets some characters as controls: 7 is bell, 8 is backspace, 9 is tab, 10 is carriage return, 13 as line feed, and others."

The result was, in referencing my table, it reversed my results.

So, please correct the ASCII table doc, not the LINE INPUT # docs.

Sigmason
sigmason
Posts: 22
Joined: Sep 21, 2006 2:18

Re: LINE INPUT #, documentation.

Post by sigmason »

I need to clarify my very first post.

Since the documentation has the ASCII character table with CR and LF
flipped, my original results actually indicate that:

LINE INPUT # will stop reading when it encounters a LF or CRLF as shown
in the original text.

I just wanted to say it outright to be precise :-)

Sigmason
counting_pine
Site Admin
Posts: 6322
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: LINE INPUT #, documentation.

Post by counting_pine »

Thanks for spotting this. I've updated the wiki:
CptAscii
sigmason
Posts: 22
Joined: Sep 21, 2006 2:18

Re: LINE INPUT #, documentation.

Post by sigmason »

Thanx,

But the doc's line of text is still a little misleading to a newbie.

You can PRINT control characters if you do something like this:

CONST AscCR = 13
CONST AscLF = 10

PRINT CHR$(AscCR);
PRINT CHR$(AscLF);
' PRINTs a carriage return followed by a linefeed.
' Note that if this ends a line in a text file opened with DOS or CMD
' EDIT the carriage return will appear as a cleffed footnote at the
' end of each line.

Sigmason
fxm
Moderator
Posts: 11131
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: LINE INPUT #, documentation.

Post by fxm »

@Jeff,

I saw your recent change: fbc: sf.net # 916 : 'LINE INPUT #1, variable' requires length parameter for ZSTRING/WSTRING PTR, but I didn't see any related update in 'changelog.txt'.
fxm
Moderator
Posts: 11131
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: LINE INPUT #, documentation.

Post by fxm »

fxm wrote: Apr 24, 2022 7:10 @Jeff,

I saw your recent change: fbc: sf.net # 916 : 'LINE INPUT #1, variable' requires length parameter for ZSTRING/WSTRING PTR, but I didn't see any related update in 'changelog.txt'.
Why not (not currently) the same change for 'Line Input' (input from the keyboard) ?
coderJeff
Site Admin
Posts: 3927
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: LINE INPUT #, documentation.

Post by coderJeff »

fxm wrote: Apr 26, 2022 19:09 Why not (not currently) the same change for 'Line Input' (input from the keyboard) ?
To be honest, once I had the 'LINE INPUT #h, *variable, maxchars' working, I committed it knowing that I would probably have to do more work on it due limited time.

Modifying the LINE INPUT parsing logic was kind of tricky because the first argument might be a variable to store input to, or it might be a variable that provides a prompt, as in: 'LINE INPUT prompt-var, variable'.

Even now can also specify maximum chars for LINE INPUT from keyboard entry too:
LINE INPUT "prompt", *zstring-var, maxchars
The trick is that there must be a "prompt" string even if it is empty "".

I'll update the changelog.txt first chance I get for the changes so far.

The other thing is, no error is thrown yet if we have a Z|WSTRING ptr and no max char length was given. Probably should have an error for that because it's still possible to overflow the buffer.
fxm
Moderator
Posts: 11131
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: LINE INPUT #, documentation.

Post by fxm »

coderJeff wrote: Apr 26, 2022 22:14 Even now can also specify maximum chars for LINE INPUT from keyboard entry too:
LINE INPUT "prompt", *zstring-var, maxchars
The trick is that there must be a "prompt" string even if it is empty "".
OK
I understand your 'tests/syntax/line-input-max.bas' file better now.
Makoto WATANABE
Posts: 215
Joined: Apr 10, 2010 11:41
Location: Japan
Contact:

Re: LINE INPUT #, documentation.

Post by Makoto WATANABE »

Dear All;
I tried to compile the sample program of "LINE INPUT # [History]2022-04-28 02:16:58".
The line below resulted in the error below.

Code: Select all

Line Input #1, *pz, maxlength
LineinputPp2.bas(14) error 3: Expected End-of-Line, found ',' in 'Line Input #1, *pz, maxlength'

Please tell me how to avoid the error.
fxm
Moderator
Posts: 11131
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: LINE INPUT #, documentation.

Post by fxm »

This new syntax is only implemented from fbc version 1.10.0 (you can find a current working version at https://users.freebasic-portal.de/stw/builds/).
Makoto WATANABE
Posts: 215
Joined: Apr 10, 2010 11:41
Location: Japan
Contact:

Re: LINE INPUT #, documentation.

Post by Makoto WATANABE »

Dear fxm

Thanks for your quick reply.
I am currently using Version 1.09.0.
The following of "LINE INPUT # [History]2022-04-28 02:16:58" means this.
***************
Version:
Before fbc 1.10.0, the third argument (the optional) was not supported.
***************
I will wait for version 1.10.0 with expectations.
coderJeff
Site Admin
Posts: 3927
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: LINE INPUT #, documentation.

Post by coderJeff »

updated in fbc/master, the expected / allowed syntax is:

Code: Select all

line input dest-var                      '' var-len or fixed-len
line input prompt, dest-var              '' var-len or fixed-len
line input prompt, dest-var, max-chars   '' *(z|wstring ptr)

line input #1, dest-var                  '' var-len or fixed-len
line input #1, dest-var, max-chars       '' *(z|wstring ptr)
The semicolon modifiers are not shown (i.e. add '?' prompt option and line continuation option)

I fixed up the tests and tested most combinations. The change may (?) break old code, but then old code would have been likely buggy too, so I think is OK. If there is a use case I missed, someone will have to post an example, start a new ticket.
fxm
Moderator
Posts: 11131
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: LINE INPUT #, documentation.

Post by fxm »

Documentation updated accordingly:
- KeyPgLineinputPp → fxm [added syntax with a length parameter for a provided string buffer of unknown size]
- KeyPgLineinput → fxm [added syntax with a length parameter for a provided string buffer of unknown size]
Post Reply