The key shortcut used is not the issue
You can check that the keyboard shortcut is being successfully set by replacing your
bash … command with
xterm (or some other graphical application). If a window appears, your shortcut is correctly set. The issue is instead almost certainly the desired command:
bash -c 'xvkbd -xsendevent -text $(date +%Y%m%d)'
In my experience, the use of
XSendEvent is unreliable.1 That might instead be the source of your issue. Using
xdotool one can select between
XSendEvent, and the former generally works for me. Your
xvkbd may have similar options.
When sending key-sequences, you need to clear the current modifiers in order to ensure you are sending the sequence you want (e.g.
test and not Super+t, Super+e, etc.)
xdotool at least has a strange behavior where if it sends events too soon, they disappear.2 This may in fact be the X server dropping events, or it may be something entirely different. In any case, you can get around this (at least in
xdotool) with a delay:
xdotool sleep 0.125 type --clearmodifiers 'string to type'
type subcommand has a
--delay option in case the initial delay is not sufficient to prevent dropping events.
I would use:
bash -c 'xdotool sleep 0.125 type --clearmodifiers --delay 125 "$(date +%Y%m%d)"'
to replicate your intended behavior, though the values used for
--delay may need adjustment, depending on your setup.
Another possible option
If you don't mind clobbering your clipboard, a better approach might be to send the default shortcut for
bash -c 'printf "%s" "$(date +%Y%m%d)" | tee >(xsel -bi) | xsel -i; xdotool sleep 0.125 key --clearmodifiers shift+Insert'
xsel to put the desired text into both the
PRIMARY selections (as ShiftInsert is not consistent in which one it uses). It then synthesizes the key sequence to paste this selection. As this requires only two synthesized keypresses, it is less likely to drop events than the other method.
If you are trying to send key input to a specific window, and it does
not appear to be working, then it's likely your application is ignoring
the events xdotool is generating. This is fairly common.
Sending keystrokes to a specific window uses a different API than
simply typing to the active window. If you specify 'xdotool type
--window 12345 hello' xdotool will generate key events and send them
directly to window 12345. However, X11 servers will set a special flag
on all events generated in this way (see XEvent.xany.send_event in
X11's manual). Many programs observe this flag and reject these events.
It is important to note that for key and mouse events, we only use
XSendEvent when a specific window is targeted. Otherwise, we use XTEST.
Some programs can be configured to accept events even if they are
generated by xdotool. Seek the documentation of your application for
Specific application notes (from the author's testing):
- Firefox 3 seems to ignore all input when it does not have focus.
- xterm can be configured while running with ctrl+leftclick, 'Allow SendEvents'
- gnome-terminal appears to accept generated input by default.
2 I will revisit this answer and expand upon this point if I learn exactly why this is the case.