I've been getting very vexed by the following.

Goal: Take the clipboard contents and paste them into another application by using a shell script called by Emacs, followed by a Return. [This is for entering a command in another application.]

Problem: A shell script using automation tools (to simulate typing) which works from a Terminal window acts goofy when called by Emacs, because all paste actions happen only after the Emacs function has completed, so the Return precedes the pasting. [Negating the value of entering the command from Emacs.]

I put steps to illustrate the problem below.

The simplified example uses xdotool, but I had the same problem when using xte. The example pastes into gedit, but the problem exists for other applications as well. Finally, I tried both shell-command and call-process-shell-command and tried all possible settings of select-enable-clipboard and select-enable-primary, all to no avail. If only I could trip the paste before the Return, I would be happy.

FWIW, I've tried such things as shell-scripts calling shell-scripts and emacs functions calling emacs functions, but all I can get is having the paste happen at the very end. I'm clearly very lost.

Any ideas about how to get the paste to happen when it happens in the script?



Steps to duplicate problem, because the explanation above is likely not sufficient.

Here is hunh.sh---copy, paste, save it, make it executable.

xdotool search --name --onlyvisible "gedit" windowactivate

# select text to replace
xdotool key ctrl+a
# paste in the clipboard
xdotool key ctrl+v
# do stupid stuff before finally hitting Return, so that it's clear
#    that the paste (ctrl-v) gets misplaced
xdotool key space space h u n h
sleep 1
xdotool key BackSpace BackSpace BackSpace BackSpace BackSpace BackSpace
sleep 1
xdotool key Return

Here is in hunh.el. Copy it, paste it, save it as hunh.el, then load it in Emacs

(defun hunh ()
 (funcall interprogram-cut-function "Fighting with clipboards is no fun")
 (shell-command "hunh.sh")
  1. Be sure that you have xdotool.

  2. Assuming you have it, open a single window for gedit.

  3. Type a bunch of garbage in the gedit window so that it can get replaced later.

  4. Run the script hunh.sh from the place you're working: ./hunh.sh

Result: Everything will work fine, with the text being replaced, some extra typing and deleting, and then a Return.

  1. Start emacs

  2. Within emacs, load hunh.el, then run its one function M-x hunh

Result: The text in gedit will be replaced with the extra typing and deleting, then a Return, and finally the paste of the text.

1 Answer 1


I'd expect that the problem will disappear if you run the process in the background with (shell-command "hunh.sh&")

  • I had a similar problem and this solution works (thanks!): can you please explain why? I'd expect a xdotool script to work even with call-process, but it doesn't record mouse clicks. Nov 23, 2022 at 21:38
  • 1
    I suspect that the problem is that the X clipboard works by making applications register themselves as "I'm the one holding it" rather than by storing the content eagerly in the X server, So when Gedit fetches the clipboard's content, it actually has to ask Emacs for it, but Emacs is stuck waiting for call-process to end before it can reply to those requests,
    – Stefan
    Nov 25, 2022 at 1:44
  • I see, thanks. Do you know if this problem is present also in Wayland? Nov 30, 2022 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.