Why don't INPUT$ and INKEY$ work in Linux console mode?

Question

I written QB64 code to try the BASIC functions INPUT$ and INKEY$.

This program runs good when it doesn't run in Linux console mode, but if we set the SW to run in Linux console mode this SW doesn't run correctly. It hangs.

I think the issue is due to Linux console behaviour. Have you a workaround?

Here is the simple code:

$CONSOLE:ONLY
_DEST _CONSOLE

PRINT "Hit a key"
A$ = INPUT$(1)
PRINT A$
PRINT "Hit a key"

B$ = ""
WHILE B$ = "": B$ = INKEY$: WEND
PRINT B$

PRINT "Hit a key"

C$ = INPUT$(1)

PRINT C$

You might do better asking this question on the more-or-less-official [QB64 support forum](https://www.qb64.org/forum/index.php). — Jeff Zeitlin, Jan 03 '19 at 14:09
Yeah, I agree. The couple of people on SO that watch for QB questions on here, from what I know, don’t support QB64 but rather the official Microsoft QB releases such as 4.5. — Robert Talada, Jan 07 '19 at 15:02
Imagine `INKEY$` returned `CHR$(0)+"K"` for the Cursor-Left key and `CHR$(0)+"OK"` for the Keypad-Left key on the numeric keypad (a.k.a. "numpad"). Now imagine that it only did that in the Windows build; Mac and Linux machines would each return different things, depending on whether you're using iTerm2, Terminal.app, xterm, rxvt-unicode, the Linux console, tmux... Now you have some idea of why it probably the functions are not implemented. Libraries like terminfo _are_ somewhat helpful, but [they're still not ideal](https://github.com/fish-shell/fish-shell/issues/2139#issuecomment-388706768). — , Jan 11 '19 at 01:47
As explained in that link, there are DEC control and shift sequences that muck things up. For example, you can do `printf '\033='; cat; printf '\033>'` to turn on "numeric keypad mode", wait for input other than Ctrl-D (try typing things and exit with Ctrl-D), and finally turn back on "application keypad mode". If you have a real numpad (not one of those silly laptop ones that have no cursor keys and require Fn-), you'll notice that the cursor keys on the editing section of the keyboard result in different byte sequences than the cursor keys on the numeric keypad, assuming Num Lock is off — , Jan 11 '19 at 02:11
I tryed to set the terminal with -icanon or raw. `stty -icano`, `stty raw`, but the program doesn't run because doesn't accept no input, also standard chars are refused. — Sir Jo Black, Jan 11 '19 at 14:12
@SirJoBlack That's because `INKEY$` is not implemented in the console for Linux (or in xterm or any other terminal, terminal emulator, etc.): QB64 doesn't even read character sequences from the TTY when using `INKEY$` and `INPUT$`. — , Jan 11 '19 at 21:15
There are additional QB64 keyboard functions _KEYCLEAR, _KEYHIT, _KEYDOWN you could look at. — eoredson, Jan 19 '19 at 06:54
@ChronoKitsune, I understand that each system has different set for the special keys (i.e.: Cursor-Key, function-Key, etc.). But if we know that fact, it don't becomes a problem. Why should be not allowed to use inkey$ to trap standard ASCII codes? I think the lack of `INKEY$` implementation is due to other facts. — Sir Jo Black, Jan 21 '19 at 13:35
@SirJoBlack It might be that too few people know how to deal with the lower level details of terminals. [Here's a version working for ASCII and nothing else; it reads exactly 1 byte and removes bytes beyond 127 (DEL)](https://gist.github.com/chronokitsune3233/34caddfb15b178067c23bdb4c39b0df7). You can use it via `DECLARE LIBRARY` (see the comment at the top), but it takes a bit more than just calling `INKEY$` or `_KEYHIT`. Don't be intimidated by the long comment at the top. You don't need to worry about it if you're only dealing with ASCII on a local machine. Hope it works for you! — , Jan 22 '19 at 04:06
The QB64 Wiki says the following: _DEST _CONSOLE can set the destination to send information to a console window using PRINT or INPUT. — eoredson, Jan 22 '19 at 07:44

score 2 · Answer 1 · answered Jan 21 '19 at 10:48

The way to get information from the console exists. We may use the command INPUT, but this doesn't allow us to avoid to hit the < enter > key to input the data. My question was about the use of INKEY$ and INPUT$ that would allow us to not hit the < enter > key.

The following code runs correctly on the Linux console, but is not the solution to this question.

$CONSOLE:ONLY
_DEST _CONSOLE

INPUT A
PRINT A

eoredson · Answer 2 · 2019-01-19T07:14:11.287

1

This keyhit function may actually work in linux:

PRINT "Hit a key:"
DO UNTIL _KEYHIT
    _LIMIT 20
LOOP
PRINT "Key pressed."

Or test for a key:

PRINT "Hit <escape>:"
DO
    _LIMIT 20
    x = _KEYHIT
    IF x = 27 THEN EXIT DO
LOOP
PRINT "Escape pressed."

edited Jan 19 '19 at 07:14

answered Jan 19 '19 at 07:02

eoredson

1,167
2
14
29

Hi, I tried to follow your suggestion. It runs correctly in Linux desktop even as `input$` and `inkey$`, but the functions that you indicated me don't run under console even setting console as raw (stty raw) or not canonical (stty -icanon). It's the same behaviour of `input$` and `inkey$`. – Sir Jo Black Jan 20 '19 at 13:10
I need a program that's run in console mode, a program that starts with the following to lines: `$CONSOLE:ONLY`, `_DEST _CONSOLE`. This two line are able to explain to the compiler that it need to produce a program that doesn't run in OPEN-GL, but in text mode only. – Sir Jo Black Jan 20 '19 at 13:18
1

Unless you can find a way to open the console for i/o, I don't see any way to do it. – eoredson Jan 21 '19 at 02:43

score 0 · Answer 3 · answered Jan 21 '19 at 03:14

0

Just ran this code: it refuses to trap any keyboard activity in Win10 as Linux.

Perhaps console mode is for output only!?

$CONSOLE
_DEST _CONSOLE
$SCREENHIDE
FOR L = 1 TO 10
   PRINT L;
NEXT
DO
    x = _KEYHIT
    IF x THEN END
LOOP
END

answered Jan 21 '19 at 03:14

eoredson

1,167
2
14
29

The way to get info from the console exists, you may use the `INPUT` command that runs also in text console. But this command does not allow you to press a key and get a result without pressing enter. – Sir Jo Black Jan 21 '19 at 10:39
1

@SirJoBlack That's because `INPUT` and `LINE INPUT` receive text from standard input, which receives it from the terminal (unless standard input is redirected). Unfortunately, both standard input and the terminal itself are buffered in some way [as I explain in this answer](https://stackoverflow.com/a/28910863). You can unset canonical mode to disable the EOF (Ctrl-D) behavior and EOL requirement for the terminal, and you can work with the controlling terminal directly (always `/dev/tty` on Linux with glibc AFAIK) to bypass the entire `stdin` redirection and buffering issues. – Jan 22 '19 at 04:45

Why don't INPUT$ and INKEY$ work in Linux console mode?

3 Answers3