I think you overlooked a theoretical problem here.
Executing readline commands makes only sense when reading something. But when a bash command runs, bash usually isn't reading anymore.
Readline is a library and independent from bash. You use it like
// start reading
char * input = readline("this is the prompt$ ");
// at this place, reading ended
// do something with input
Readline can only execute its commands (e.g.
readline() is running.
When you enter
imaginary_cmd_for_executing_readline forward-word in
bash and press enter, then
readline() already terminated and therefore cannot execute
forward-word anymore. In the source code of bash (or in a custom loadable builtin), you could call the C-function behind any readline command yourself (e.g.
rl_forward_word instead of
rl_get_previous_history instead of
previous-history), but these would probably fail, as they read and write to memory areas that might not be usable at that time. And even if they were, you wouldn't get any result, as those only modify the linebuffer and do not actually print anything.
Bash registers some functions in readline that may run while
readline() is still running, for instance when
- a signal arrives (for instance when pressing ctrlc).
- one of bash's custom readline commands is executed (e.g.
shell-expand-line); this only happens when entering a registered key sequence.
- any key sequence registered with
bind -x is entered.
Inside such a hook, you could theoretically execute a readline command. But all of them require keystrokes themselves as a trigger, so there is no benefit in using them over a direct bind. But most of all, there is probably no point in running a readline command on its own when not editing a line, as I explained before.
If you really must, you can temporarily bind any key to the command you want to run, and then send that key stroke automatically from the background to the terminal itself, see Can bash write to its own input stream?.