Send standard output of commands to keyboard input

[tkna91]

I thought it would be useful to be able to send the standard output of a command to keyboard input, as in the following image. How do you feel about this?

Example 1

[ids]
0001:0001

[main]
space = overload(layer1, space)

[layer1]
semicolon = command-out(echo -n $(date +%Y%m%d-%H%M%S))
r = command-out(sudo --user user1 /home/user1/.local/bin/msg/sales_report_daily.sh

[herrsimon]

Apart from increased code complexity, I don't see a real use for such a command. After all, you can already achieve what you want with dedicated tools (such as xdotool), for example with

semicolon = command(xdotool type "$(date +%Y%m%d-%H%M%S)")

Also, as I initially had the same tendency as you, a word of warning: Your r binding is not good style, as it makes apparently personal information (to user1) available systemwide. Such functionality is better implemented directly as a macro in your editor.

[tkna91]

@herrsimon I got the desired results below. Thank you.

# ydotoold &
 423065
# 

/etc/keyd/hhkb.conf

[main]
space = overload(layer1, space)
[layer1]
a = command(ydotool type "$(date +%Y%m%d-%H%M%S)")

Your r binding is not good style, as it makes apparently personal information (to user1) available systemwide.

Indeed, when I think about it, it is a dangerous form of operation for a super user to touch a general user's resources, because user never know what kind of trap may be set. We should reduce contact to the maximum extent possible, or at least avoid executing it. I understood it in my own way. Thank you for your kind advice.

[rvaiya]

I'm not entirely opposed to this.

a word of warning: Your r binding is not good style, as it makes apparently personal information (to user1) available systemwide. Such functionality is better implemented directly as a macro in your editor.

+1. This sort of thing is why I was originally reluctant to implement command() at all. Though now that pandora's box has been opened, it isn't too much of an additional risk to add something like command-out.

I've been contemplating allowing the user to input text and execute macros directly, which could also be used in conjunction with command() in a similar fashion to your ydotool solution.

E.G

command(date|keyd --input-text)

My main problem with this is that there isn't a 1-1 mapping between text and input codes. The natural solution is to use KEY_A for a, KEY_B for b etc but that assumes a qwerty layout on the display server (potentially reasonable) and doesn't account for non-printable/typable characters. I assume ydotool takes this approach, though I haven't used it.

[tkna91]

I ran the following 1-2, a-g

[main]
space = overload(layer1, space)

[layer1]
# https://github.com/ReimuNotMoe/ydotool/blob/master/manpage/ydotool.1.scd

1 = command(ydotool type "$(date)")
2 = command(ydotool type "$(date +%Y%m%d-%H%M%S)")
a = command(ydotool type 'a')
b = command(ydotool type 'b@&')
c = command(ydotool type 'cＣ'
d = command(ydotool type 'dシ')
e = command(ydotool type 'e漢字')
f = command(ydotool type 'f👍')
g = command(ydotool type 'g🤤')

result

Sun May 29 02+53+56 PM JST 2022
20220529-145359
a
b"'
c
d
e
f
g

As for "1" colon and "b" @&, I am using a Japanese keyboard, which makes a difference in the layout. As you pointed out, the standard specifications (US 101 keyboard with ASCII only?) I guess that is the case.

It may not have much to do with the essence of what we are doing now, but I was curious about the process that remained.

# pgrep -a ydotool
574279 ydotoold
583161 ydotool
583164 ydotool
583175 ydotool
583183 ydotool
583185 ydotool
583186 ydotool
583187 ydotool
# systemctl restart keyd
# pgrep -a ydotool
574279 ydotoold
#

When the command is executed directly, no process seems to remain.

# pgrep -a ydotool
574279 ydotoold
# ydotool type 'a'
a# pgrep -a ydotool
574279 ydotoold
#

[tkna91]

In a naive way, I imagine the following policies, etc.

1. Do nothing. Leave such processing to the following clipboard tool, etc., and leave it outside the scope of the area handled by keyd https://github.com/astrand/xclip https://github.com/bugaevc/wl-clipboard

2. Process only ASCII. Do not take into account differences in key sequences.

3. Output according to some conversion table.

   • dumpkeys https://man.archlinux.org/man/dumpkeys.1.en
   • grep KEYMAP /etc/vconsole.conf https://man.archlinux.org/man/vconsole.conf.5
   • localectl status, localectl list-keymaps https://man.archlinux.org/man/localectl.1
   • find /usr/share/kbd/keymaps/ -name \*.map.gz
   • UTF-8
   • XKB layout
   • etc..

[rvaiya]

I ran the following 1-2, a-g [...]

Thanks for running these experiments. As expected it chokes on unicode since it is keycode driven.

As for "1" colon and "b" @&, I am using a Japanese keyboard, which makes a difference in the layout. As you pointed out, the standard specifications (US 101 keyboard with ASCII only?) I guess that is the case.

Indeed, the config syntax is based on keycodes which use the kernel names (which are in turn based on a US ANSI layout). This shouldn't prevent you from remapping keys, but you may have to use -m to figure out which keycodes correspond to the physical positions on your board. I need to document this better.

This is also the principal difference between evdev based tools like ydotool and display server tools like xdotool. The latter can output keysyms directly, bypassing any translation done by the display server, which means it will always produce the correct output irrespective of the keymap.

It may not have much to do with the essence of what we are doing now, but I was curious about the process that remained. [...]

Thanks for reporting this. It is a bug. The processes are zombie processes, which means they have actually terminated but still show up in your process list. It should be fixed in the latest commit.

---

In a naive way, I imagine the following policies, etc. [...]

Do nothing

+1

Process only ASCII. Do not take into account differences in key sequences.

This is currently how macros (and keyd generally) work. The user is expected to understand that keyd is a low level tool for manipulating input codes (like QMK). For English ANSI boards the difference between keycodes and keysyms can mostly be ignored, but ultimately converting keycodes into symbols is the display server's job.

Output according to some conversion table.

Also known as the layout :P.

I am inclined to agree that proper text input is a job for display server level tools, though it probably makes sense to allow macros to be executed directly using the client. Adding a 'raw' mode so the user can do input(Hello World) instead of macro(Hello space World) seems like a natural extension.

[rvaiya]

This should now be possible using a combination of command() and the new input command.

E.G

home=command(date|keyd input)

[tkna91]

Checked. Works very quickly, clear and comfortable. Thank you!