command() not working

[ziontee113]

Hi, I'm trying out command() and I can't get it to work.

Here's my example setup:

[ids]
*
[main]
capslock = overload(capslock, esc)

[capslock]
s = command(firefox)
g = command(~/.scripts/google_search.sh)

I can't get command() to work at all. Nothing happens when I press the combination. I can remap keys, run macro(), but I can't use command().
What am I doing wrong? Am I missing something? Is there a way that I can see the errors if I do something wrong with command()?
Thank you :)

[nsbgn]

command() is run as the user that runs keyd, which is probably root. Root's home directory is not the same as yours (ie not ~). It will probably work if you do /home/<user>/.scripts/google_search.sh instead (and other environment variables that might be needed are set, which is why firefox doesn't work), but this is not recommended since you would be running the command as root. It's better to configure things like this in your window manager, or perhaps via something like https://github.com/waycrate/swhkd.

As for seeing errors:

sudo journalctl -u keyd

(@rvaiya, innocent question: do you know what other security implications there would be? Running a command as another user via su <user> -c <command> still feels wrong, but I must admit that I'm not sure about the actual issue. Is privilege escalation more of a risk when the process is spawned directly by keyd?)

[rvaiya]

or perhaps via something like https://github.com/waycrate/swhkd.

My understanding is that swhkd is just another evdev based tool which will have similar drawbacks, though I have never used it.

Running a command as another user via su -c still feels wrong

+1

Is privilege escalation more of a risk when the process is spawned directly by keyd?)

Not that I am aware of, but using su requires you to hardcode the target user. This is probably fine on single user systems (but then so is root (mostly)). On multi user systems where not all users are trusted it is almost certainly a bad idea to provide any user with a way to execute commands as a another user. Having said that, I assume such systems are probably quite rare these days.

Given that it is almost always possible to achieve this using some display server tool (e.g xbindkeys, sway config, etc), and most of the applications one would be interested in running are graphical (necessitating faffing about with (WAYLAND_)?DISPLAY), there isn't really a compelling reason to use a third party tool for this. There are likely configurable DE specific behaviours which can't be effected with an external command anyway.

command() is mostly useful in instances where the command really does need to be run as a specific user and doesn't care about the current session (e.g htpcs/embedded projects).

[ziontee113]

Thank you guys for the answer. Maybe I misunderstood the purpose of command() for something like Autohotkey. Unfortunately I tried this code and still fail:

command(/home/username/.scripts/google_search.sh)

Still nothing happens, and sudo journalctl -u keyd doesn't show anything about executing commands().

I guess the solution is to remap the keys I want to special unicode characters, then use those characters to map whatever I want with my window manager?

[rvaiya]

By default stdout/stderr are discarded to avoid polluting the log file. You can explicitly redirect them by appending something like > /tmp/logfile 2>&1 to the end of the command. I'm assuming google_search.sh launches a browser or some other graphical program, in which case you will also need to set the appropriate session variables (e.g $DISPLAY).

I would still strongly advise against doing this unless you have a good reason. You are better off doing something like capslock = overload(meta, esc).

and then binding M-<x> in your window manager.

[ziontee113]

Thank you :) I will remap the keys to another key and use that key to trigger applications / scripts using my Window Manager.