There’s no shame in that. Yes, there is documentation, code to be read, and debuggers to be used. But sometimes you just need to “see” what is happening.
So what warrants this reaction? Well, my project of shoehorning command history into plan9 still has some issues. One of them is not always working over drawterm, which is kind of annoying when working on remote systems. Especially with repetitive tasks like working on a sensor, where the development cycle is compile, run, analyze and repeat. Small commands that are not long enough as to feel like mousing around with a mouse is usefull. And not short enough to just type them in passing.
So let’s sniff what’s actually appearing on the application side. Code proudly referenced from riow program in 9front.
Some context: as understood from a quick glance at the riow code (true, I should research this more, when it’s time), keyboard input is presented as a “train” of characters or runes with a tag at the beginning. Either there is a control (ALT or SHIFT or CTRL or MODE or …) key being pressed (‘K’ character) or released (‘k’ character) OR a regular character is being sent (‘c’ character).
The referenced code looks for a control character to figure out if a modifier key is being pressed, followed by a regular character. In my case (CTRL + UP/DOWN) something is not behaving as expected.
Let’s do some tests and compare the results!
Tests are done by typing command lc followed by ENTER, then pressing the CTRL key and then the UP key.
9front in QEMU - regular character denotes UP:
9front on Raspberry Pi 1 with keyboard & mouse - regular character denotes UP:
9front over drawterm (CONF=linux) on wayland - regular character denotes CTRL:
9front over drawterm (CONF=unix) on wayland - regular character denotes Shift Out:
9front over drawterm (CONF=linux) on x11 - regular character denotes Shift Out:
9front over drawterm on windows - regular character denotes Backspace:
Now this is certanly a wide collection fo results. Whan can we deduce from this?
Bare metal and QEMU are identical, so let’s assume this is how it is read from the physical input device.
- OK as it is.
Windows and Linux on Wayland have the right keys in control (k) block, but not in regular character (c).
- Fixed now in current version of histw by checking only (k) for key combinations.
Unix on X11 or wayland if a wild mix.
- Can’t fix in histw.
Conclusion of this test?
All signs point to how drawterm interprets or sends input information forward. This might be a future mini project to look into that. Might! One step at a time.
For now, let’s take the small win and use the latest and greatest (drawterm on Windows or Linux compiled for wayland) and live with the fix in histw for now.
Before we dive deeper into this rabbit hole, let’s figure out why printing out long commands on the input line stopped working.