CLI console and Script executed

[cybermaus]

So, after playing with this a little, I find that things do work, especially if I see them described as functionality of this product.

That is, I got it to work when the display manager is started.
When booting into console, I was not able to get it to work, also not when I ensure the service was started and I ran the key-mapper-control --command start --device "Dell Dell USB Keyboard" --preset Test

Before finding this, I played a little with evdev driver, and in it;s code that worked as well on CLI as on X. But in the roadmap, I see evdev usuage is for the future, so not yet.

• So is it correct this will not work on non X console? (Edit: solution see below)

Also, there is nowhere described (that I can find it) any ability to run shell scripts based on keypresses.

Because that is why I was playing with evdev myself. Ultimately, I want a small numpad keyboard to control processes, mostly by sending CURL commands to other devices.

• So is it correct there is no script calling? (Edit: solution is custom mod/build, see below)

[cybermaus]

Strike that... Testing again, now it works from the CLI console.
That means this is useable for me. I can probably either hack in, or properly build in the shell script calls

[sezanzeb]

what is key-mapper-exit?

[cybermaus]

The fixed name of the exit program, that the user (me, or whoever uses this) needs to write and place in $PATH.
Specifically, for me this one

For me the name seemed to make sense. I realise now that for you it may seem intrusive, claiming a name that clearly belongs in your name space. Sorry.

Edit/Addendum: So the original though was that "key-mapper-exit" would/could return a string in the form of "k(a).k(b)" or something that could be interpreted as a macro. Not that I needed that. But it seemed like something that fitted the key-mapper goals.

[sezanzeb]

I realise now that for you it may seem intrusive, claiming a name that clearly belongs in your name space. Sorry.

No problem. I was just curious what that command is about

I cannot get the parse() function to work

Lots of examples for the parse function are here: https://github.com/sezanzeb/key-mapper/blob/main/tests/testcases/test_macros.py

[cybermaus]

Ok, I got it to work! commit (in my personal fork) e74bebd

And it turns out I have use for it: In most conditions I need to run curl commands and even a systemctl command. But in one specific condition, I can get away with just the Q key pressed, so I return: 'k(KEY_Q)'

And this now works!
Exit example / key mapping example

Thanks for your help.

---

BTW: though this is all personal use, I did considered security. I think best way would be to check who is the owner of the exit program, and its sticky bit. And if sticky bit set, run the subprocess under that user, and if not set, run it as user nobody

This is not implemented though. At this moment, there is the lesser security that any hacker would need to create the exit program in the $PATH of root, which is also already a problem.

---

BTW2: I realise I stubbornly keep calling this an "exit program" where you would call it a (somewhat rudimentary) plugin.
This shows my long experience (or maybe deformation) as IBM midrange programmer, where exit program is the normal terminology.

Though (in my mind) there is truly a difference. An exit program is hardcoded, the application calls the program if it can find it, thus allowing program to temporary make a detour (an 'exit') from native programming.

Whereas a plugin system has a external system announce and register itself, in a much more flexible way. Often multiple plugins can register, often they also add themselves to menu classes and screen elements, etc.

[sezanzeb]

And this now works! Thanks for your help.

Great, you're welcome!

I wonder if parsing during runtime is a large bottleneck, but it's certainly an interesting idea I didn't think of yet. To make it faster, you could provide k(KEY_Q) as a parameter to the macro function, something like exitpgm(dev, auto, k(q)). In that case you could parse the macro already when the injection starts.

where exit program is the normal terminology

Yeah, I never heard of exit other than in bash and python to close the shell.

Whereas a plugin system has a external system announce and register itself, in a much more flexible way

Yes, unfortunately I didn't come up with a concept of how that would look like. If you have some ideas you are welcome to throw them into a comment on the issue #80