LINE INPUT #, documentation.
LINE INPUT #, documentation.
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
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
Re: LINE INPUT #, documentation.
You have a bit of sample code to test it? If so I'll test it on linux too.
Re: LINE INPUT #, documentation.
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
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
Re: LINE INPUT #, documentation.
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
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
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: LINE INPUT #, documentation.
Thanks for spotting this. I've updated the wiki:
CptAscii
CptAscii
Re: LINE INPUT #, documentation.
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
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
Re: LINE INPUT #, documentation.
@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'.
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'.
Re: LINE INPUT #, documentation.
Why not (not currently) the same change for 'Line Input' (input from the keyboard) ?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'.
Re: LINE INPUT #, documentation.
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.
Re: LINE INPUT #, documentation.
OK
I understand your 'tests/syntax/line-input-max.bas' file better now.
-
- Posts: 232
- Joined: Apr 10, 2010 11:41
- Location: Japan
- Contact:
Re: LINE INPUT #, documentation.
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.
LineinputPp2.bas(14) error 3: Expected End-of-Line, found ',' in 'Line Input #1, *pz, maxlength'
Please tell me how to avoid the error.
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
Please tell me how to avoid the error.
Re: LINE INPUT #, documentation.
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/).
-
- Posts: 232
- Joined: Apr 10, 2010 11:41
- Location: Japan
- Contact:
Re: LINE INPUT #, documentation.
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.
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.
Re: LINE INPUT #, documentation.
updated in fbc/master, the expected / allowed syntax is:
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.
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)
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.
Re: LINE INPUT #, documentation.
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]
- 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]