Up arrow does not scroll through command buffer

I have this issue with my IF interpreter. Not critical, but mildly annoying and almost every tester mentions it.

The interpreter is written in C and I compile it for Windows, Linux and macOS. It runs in a CMD (Windows) or terminal (Linux and macOS) window.

The issue is with the up arrow key. When you are at the OS command line level in a CMD or terminal, up arrow scrolls through the command buffer.

Now, when the interpreter is running I see the following behavior:

Windows CMD: the up arrow key gives the previous game commands, just like I want it to.

macOS and Linux terminal: the up arrow key produces ^[[ gibberish on the command line.

What I think is that the up arrow key code is directly fed into the interpreter without the terminal kicking in to catch it.

Is there a way that I can change this behavior so up arrow will scroll through the command buffer?

(I did search for this but I can only find issues at the OS level itself, not with applications that use command lines).

It’s worse than just up/down. You don’t even get left/right. Windows provides a line editor when you call functions like scanf(). This makes it easier to write interactive CLI programs. You don’t get that on macOS or Linux (or any other system; only Windows does this AFAIK.)

You need to implement your own line editor (which might be difficult if you’re not familiar with Unix terminal standards,) or use an existing one like readline (GPL licensed) or libedit (BSD licensed.)

2 Likes

Thank you for the explanation. I will check out the editors you mentioned.

Sorry for the bump, just saw this on suggested topics and thought it might be useful to someone.

Generally on Linux people use rlwrap for stuff like this – just pass the usual commands for launching the game as arguments to rlwrap and it magically works. History is automatically preserved in between sessions, which is nice.

Also works well on Windows consoles that are not cmd.exe (like Cygwin console or WSL’s conhost).

1 Like