The 1st call to xdotool search from within a graphical application returns a BadWindow error:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  3 (X_GetWindowAttributes)
  Resource id in failed request:  0x4e011ca
  Serial number of failed request:  318
  Current serial number in output stream:  319

The 2nd and subsequent calls don't return errors. If called directly from bash, no errors are returned.

It's reproducible, suffice it to create a simple script with these lines:

#!/bin/bash
echo 'Attempt #1'
xdotool search --class puddletag
echo 'Attempt #2'
xdotool search --class puddletag

and then run it from bash and a graphical app (I called the script from plugin Custom Commands in quodlibet, or from a .desktop file as an external editor in geeqie). puddletag can be replaced with any other suitable app name. When called from bash directly, these were the (correct) results

Attempt #1
65011714
65011732
Attempt #2
65011714
65011732

but when called from either quodlibet or geeqie, the first search call failed and the second succeeded:

Attempt #1
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  3 (X_GetWindowAttributes)
  Resource id in failed request:  0x4e011ca
  Serial number of failed request:  318
  Current serial number in output stream:  319
Attempt #2
65011714
65011732

This error was not tied neither to quodlibet nor to geeqie: when called from any graphical application, whether GTK+ or Qt, xdotool search always failed with the BadWindow error on its first invocation.

I'm using:

xdotool 3.20130111.1-5
xserver-xorg 7.7+7ubuntu2
xfce 4.11
Xubuntu 14.10

--onlyvisible limits to the current desktop, and --maxdepth can't guarantee elimination of only non-visible windows.

Other functions dealing with screens in libxdo uses only the integer index of screens while xdo_get_window_location returns X11's Screen structure, and only if the caller wants it. This breaks the convention used otherwise in the library.

(Originally reported as issue 72 on code.google.com)

$ xdotool search --onlyvisible Chrome get_desktop_viewport %1
Defaulting to search window name, class, and classname
Expected 2 items for _NET_DESKTOP_VIEWPORT, got 12
-452067296 32767
$ xprop -root | grep _NET_DESKTOP_VIEWPORT
_NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

% xdotool type --clearmodifiers --delay 0 '////'
qqqq

My xmodmap -pke: https://paste.xinu.at/Nq9Jz/sh

$ xmodmap -pm
xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        ISO_Next_Group (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

The library function xdo_active_keys_to_keycode is redundant and has a misleading name since it only returns the modifiers currently active, not any key that is being pressed.

When using the "xdotool key", some characters show incorrectly.
Odiaeresis, Udiaeresis, Gbreve and Scedilla show up as ö, ü, ğ and ş instead of Ö, Ü, Ğ and Ş.

Not a big problem, it can be worked around by using "dead_diaeresis O", "dead_diaeresis U", "dead_breve G" and "dead_cedilla S", but I thought you'd like to know it.

(Originally reported as issue 71 on code.google.com)

If I run xdotool selectwindow and click on the currently focussed urxvt window, it returns 83892796. However xdotool getwindowfocus and xdotool getactivewindow both return 81788939, as does xdotool search --class urxvt.

If I suffix these commands with getwindowname then the first one returns a blank line and the others all return 0:6:pac - "adam@pacific".

This is on openSUSE 12.2 with the latest version from github. If I use the 20110530 release, it's the same except that xdotool selectwindow also returns the following:

findclient: 83892797
findclient: 83892796

Taken from a bug report on Google Code:

What steps will reproduce the problem?
Having this in .xbindkeysrc:

"sleep 0.1 && xdotool type --clearmodifiers --args 1 123123 && xdotool key --clearmodifiers Tab && xdotool type --clearmodifiers --args 1 123123"
m:0x40 + c:10
Mod4 + 1

(That's for filling 2 textboxes in a browser)

push win(mod4)+1

sometimes the mod4 key is "stuck"
that means pressing e.g. TAB acts like win+TAB

What version of the product are you using? On what operating system?
20110530.1-6
xubuntu 13.04

My addendum:

"xdotool sleep 0.2 type --clearmodifiers test123"
m:0x14 + c:49
Control+Mod2 + grave

I'm experiencing this issue too. I think the problem is that I hit the macro by first pressing control then a moment later pressing grave, and to release the key combination I let go of everything at once. So, the macro thinks it needs to put the modifier back into the "down" state, even though it has already been released.

To put it more succinctly, I suspect that the problem is that clearmodifiers doesn't keep track of changes to key state since the modifiers were saved.

It would be nice if the window stack could be used with the exec command, to pass the matched window id(s) on to other programs. Right now I have to do something like this:

windowid=$(xdotool search --sync --name whatever getwindowid)
wmctrl -ir $windowid ...

It would be nifty to be able to do it like this, though:

xdotool search --sync --name whatever exec --sync wmctrl -ir %1 ...

esp. if it then supported %@ for running the command once for each window in the stack.

I am getting this error during make

./libxdo.so: undefined reference to `xkb_keysym_to_utf32'

Here is a full log.

Both libxkbcommon-dev and libxkbcommon-x11-dev are installed.

Hi,

I'm redirected from this ticket:

https://sourceforge.net/p/keepass/bugs/1123/

Is it the good place?

Regards,
Sylvain.

I am not sure if this is an issue with gnome or xdotool, but I created a script which hides gnome-terminal when it is visible, and shows it when it is hidden. I use the following line to do this.

xdotool search --onlyvisible --class 'Terminal' windowunmap %@ || xdotool search --class 'Terminal' windowmap %@

The problem is that when I hide and then unhide the gnome-terminal window, a tiny extra window appears (of the same class and name). Only one extra window appears, no matter how often I hide/unhide gnome-terminal. The window contents is black. i can't do anything in there. It isn't a big problem, but it clutters the window list and doesn't seem to be the expected behaviour.
I also can't close the window.

I am running ubuntu 12.04 with gnome-shell. These are some of the details of my setup.

||/ Name Version Description
+++-==============-==============-============================================
ii gnome-shell 3.4.1-0ubuntu2 graphical shell for the GNOME desktop
ii xdotool 1:2.20110530.1 simulate X11 keyboard/mouse input

Linux dolfdesktop 3.2.0-34-generic-pae #53-Ubuntu SMP Thu Nov 15 11:11:12 UTC 2012 i686 i686 i386 GNU/Linux

Cheers,

Dolf.

https://github.com/soliton4/nodeMirror/releases/tag/0.1.18

a x11 terminal forwarded to the web ;)

wmctrl can list all visible windows across all desktops in one go, along with their window name, class, window id, pid, and desktop number:

$ wmctrl -lpx
0x01800003 -1 5733   xfdesktop.Xfdesktop   pacific Desktop
0x04200003 -1 6104   gkrellm.Gkrellm       pacific gkrellm
0x0520000b -1 6186   urxvt.URxvt           pacific watchlogs-system
0x01600004 -1 5732   xfce4-panel.Xfce4-panel  pacific xfce4-panel
0x05e00032  5 23702  skype.Skype           pacific Skype
0x01200047  0 26835  emacs.Emacs           pacific focus-emacs-frame
0x0500000b  1 4759   urxvt-256color.URxvt  pacific adam@pacific

This is very convenient for scripting.

I pulled an older version and it worked as intended.
What happens with older versions:

$ xdotool getwindowfocus key --clearmodifiers ctrl+v ctrl+v Return
^V

xev reports:

$ xdotool key --window 0x2e00001 --clearmodifiers ctrl+v
KeyPress event, serial 198, synthetic YES, window 0x2e00001,
    root 0x0, subw 0x0, time 0, (1,1), root:(1,1),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 198, synthetic YES, window 0x2e00001,
    root 0x0, subw 0x0, time 0, (1,1), root:(1,1),
    state 0x4, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (16) ""
    XmbLookupString gives 1 bytes: (16) ""
    XFilterEvent returns: False

KeyRelease event, serial 198, synthetic YES, window 0x2e00001,
    root 0x6b66b540, subw 0x0, time 0, (1,1), root:(1,1),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 198, synthetic YES, window 0x2e00001,
    root 0x6b66b540, subw 0x0, time 0, (1,1), root:(1,1),
    state 0x0, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (76) "v"
    XFilterEvent returns: False

Newer versions:

$ /usr/bin/xdotool getwindowfocus key --clearmodifiers ctrl+v ctrl+v Return
vv

xev reports:

$ /usr/bin/xdotool key --window 0x2e00001 --clearmodifiers ctrl+v
KeyPress event, serial 198, synthetic YES, window 0x2e00001,
    root 0xae8de07, subw 0x0, time 0, (1,1), root:(1,1),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 198, synthetic YES, window 0x2e00001,
    root 0xae8de07, subw 0x0, time 0, (1,1), root:(1,1),
    state 0x0, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (76) "v"
    XmbLookupString gives 1 bytes: (76) "v"
    XFilterEvent returns: False

KeyRelease event, serial 198, synthetic YES, window 0x2e00001,
    root 0xa6dccf4, subw 0x0, time 0, (1,1), root:(1,1),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 198, synthetic YES, window 0x2e00001,
    root 0xa6dccf4, subw 0x0, time 0, (1,1), root:(1,1),
    state 0x0, keycode 55 (keysym 0x76, v), same_screen YES,
    XLookupString gives 1 bytes: (76) "v"
    XFilterEvent returns: False

The last version that exhibits the correct behaviour seems to be edbbb7a.

As per my post from October 2012, the xdotool project is currently in a confusing state for newcomers where it's hard to find out what the authoritative location for code and issue tracking is. It would make a big difference if you took a few minutes to board up the broken windows, e.g.:

• fix the README to refer to this github repo, not to http://www.semicomplete.com/projects/xdotool/ which has been broken for a long time now.
• go through the 31 issues at https://code.google.com/p/semicomplete/issues/list, copy any which are still relevant to github, then close all of them with a comment explaining that development has moved to github
• fix http://www.semicomplete.com/projects/xdotool/

Thanks!

I used commands like xdotool click --position 867 523 --window 79691777 1 to control a window in the background (flash in chrome), below all other windows.
This is used to work, but after the latest system update, the window is always focused and raised to foreground, which is very annoying.
Is there a way to prevent that focusing?

On xfce/debian

xdo_get_active_modifiers() returns a pointer to a struct instead of returning the values in arguments like all similar functions in the library does.
By changing this there would be no need for the xdo_active_mods_t struct either.

I frequently find myself wanting to have search look over the stack instead of the full window list.

Here's an example:

xdotool search --class google-chrome \
  search --stack --name github \
  set_desktop_for_window %@ 2

I have tried to run the tests, but it fails:

Running test_basic.rb
Warning: Tried to connect to session manager, Could not open network socket
Setting up keymap on new server as us
Warning: you should require 'minitest/autorun' instead.
Warning: or add 'gem "minitest"' before 'require "minitest/autorun"'
From:
  /usr/lib/ruby/2.1.0/test/unit.rb:1:in `<top (required)>'
  test_basic.rb:4:in `<main>'
MiniTest::Unit::TestCase is now Minitest::Test. From /usr/lib/ruby/2.1.0/test/unit/testcase.rb:8:in `<module:Unit>'
/usr/lib/ruby/2.1.0/test/unit.rb:676:in `<class:Runner>': undefined method `_run_suite' for class `Test::Unit::Runner' (NameError)
  from /usr/lib/ruby/2.1.0/test/unit.rb:261:in `<module:Unit>'
  from /usr/lib/ruby/2.1.0/test/unit.rb:15:in `<module:Test>'
  from /usr/lib/ruby/2.1.0/test/unit.rb:7:in `<top (required)>'
  from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
  from /usr/lib/ruby/2.1.0/rubygems/core_ext/kernel_require.rb:55:in `require'
  from test_basic.rb:4:in `<main>'
make[3]: *** [do-test] Error 1
make[3]: Leaving directory `/home/daniel/Vcs/xdotool/t'

% ruby --version
ruby 2.1.2p95 (2014-05-08) [x86_64-linux-gnu]

What am I missing?

Is my Ruby stack too new? (MiniTest::Unit::TestCase is now Minitest::Test)

I want to select all windows on the current desktop which are NOT named 'Gnome-Pie'

Since extended regexps aren't supported (eg 'xdotool search --desktop 1 '(?!Gnome.Pie)' just gives an error about 'failed to compile regex').. I considered that the most sensible way to make this kind of matching a possibility,
would be to have a --subtract option.
This would store the old windowstack, and once the search results are in, set the final windowstack to contain only the windows which are in the old stack and not in the new one..

Some of the newer shells (unity, some KDE plasma set ups) can place the menu bar for all programs at one place on the screen like the Mac does.

If you do a movewindow --relative with y=0 or y=y (e.g. movewindow --relative -- -100 0) you will observe that the window moves down slightly by the height of the menu bar.

I left the same issue on the google code tracker because I didn't know which was active.

When I do

xdotool type "ABCDEFGHIJKLMNOPQRSTUVWXYZ" 

I get

ABCDEFGHIJKLMNOP�RSTUV�XYZ

instead of

ABCDEFGHIJKLMNOPQRSTUVWXYZ

I have an azerty keyboard and I'm using xdotool on a ubuntu 14.04 64bit.

When I switch my keymap to qwerty I get the expected result. (ABCDEFGHIJKLMNOPQRSTUVWXYZ)

Let me know if you need more information about my machine / settings / ...

Thank you for this awesome tool ! :)

There seems to be some problem when sending keys to another firefox window when the currently focused window is a firefox window belonging to the same firefox instance. For example, if I had a key binding configured in my window manager mapping some key to 'xdotool search SomePage key control+r', sometimes the event will be received by the currently focused firefox window instead of the one showing a page titled "SomePage". This doesn't follow a systematic pattern or at least I couldn't find one. It could be that firefox confuses the focused window with the one receiving the KeyPress event. Furthermore, I don't know if some behavior is considered standard in this case: should the application attribute the KeyPress event to the target window or to the focused window?

I'm using firefox 26, xdotool 2.20110530.1, dwm 6.0, and arch: Linux localhost 3.12.7-2-ARCH #1 SMP PREEMPT Sun Jan 12 14:02:09 CET 2014 i686 GNU/Linux

Using xdotool to insert charackters like äöü is really slow.

Inserting a

$ time xdotool type "a"; time xdotool type "ä"
a
real    0m0.014s
user    0m0.001s
sys 0m0.002s
ä
real    0m0.072s
user    0m0.002s
sys 0m0.002s

A more extreme example of inserting 10 characters at a time:

$ time xdotool type "aaaaaaaaaa"; time xdotool type "ääääääääääää"
aaaaaaaaaa
real    0m0.281s
user    0m0.003s
sys 0m0.002s
ääääääääää
real    0m2.060s
user    0m0.003s
sys 0m0.006s

It does not take much cpu though as the user and sys time are really low. At least not the xdotool process. It also does freeze X for that time: no screen updates besides mouse movements are rendered.

Using "time xdotool key adiaeresis" can also used to produce the same effects.

Could you add an option to dump the translation table that had been keysym_charmap[] in xdo_util.h in an easily machine-readable format?

One of my tools used to rely on downloading it from this repo, but now that the method has changed, my work-around using the old version (from before bbf0e70) will probably become out of sync soon.

Best regards, M.K.

hi, im trying to use libxdo for a private project.

i'm doing two easy calls to xdo_new and xdo_move_mouse_relative. but when i tried to build my file using this command:

g++ LinuxTest.cpp -lXtst -lX11 -lxdo

but i'm getting:

LinuxTest.cpp:(.text+0x34): undefined reference to `xdo_new(char const*)'
LinuxTest.cpp:(.text+0x54): undefined reference to `xdo_move_mouse_relative(xdo const*, int, int)'

xdo.h is located at "/usr/local/include/" and libxdo.so is in "/usr/lib/"

Hello,

My idea is to use xdotool to run indicator-synapse with a shortcut. But in Xubuntu 14.04 (Xfce 4.10) xdotool doesn't work correctly with the shortcut assigned. This is my little script:

!/bin/bash

xdotool mousemove 1050 5 click 1 mousemove restore

And when I select the shorcut it seems that goes to the assignated coordinates and returns to the original position but the click doesn't has effect, the indicator-synapse icon changes its color (this means that is clicked), anything else happens.

This happens in my desktop Xubuntu install and in a Virtualbox VM configured for reproduce the issue. Under Unity desktop runs perfect, no problem at all.

Please, could you suggest me a solution?

Thank you very much and very best regards.

If I'm not missing something, the last released version (xdotool-2.20110530.1) is ancient (from 2011). Is a new release planned and what's stopping it?

xdo_getwinprop breaks the naming convention and should probably be named something like xdo_window_get_prop, judging by the name of other functions. There are also other functions that probably should be renamed. The convention that probably would be simplest to conform to would be xdo_window_verb_[...] for all functions that takes a Window argument as the second argument and xdo_verb_[...] for all other functions. A, imho, better convention would be xdo_verb_[things being acted on]_[...], so for example xdo_move_mouse, xdo_type_window (maybe rather xdo_enter_text_window), xdo_set_prop_window, and so on.

It would be incredibly helpful if mousemove distinguished percentages from plain numerical coordinates.

Many GUI layouts are proportional. For example. in GPick, if the Palette panel is visible, moving to the (98%, 50%) mark will always put you in the Palette. Or in Sakura, moving to the 0.5%, 1% mark will get you to the first tab (assuming multiple tabs are open))

Currently, xdotool mousemove 50% 50% simply moves to 50,50. The change I'm suggesting would make xdotool mousemove 50% 50% move to the centre of the current screen, and xdotool mousemove -w $WINDOW 50% 50% move to the centre of the specified window.

Hey. I'm no X11 guru, so this is possibly an issue with Xtightvnc. Is it?

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bd7e8f in _xdo_populate_charcode_map (xdo=0x61ba80) at xdo.c:1304
$1 = (XkbDescPtr) 0x0
$2 = 8

(gdb) where
#0 0x00007ffff7bd7e8f in _xdo_populate_charcode_map (xdo=0x61ba80) at xdo.c:1304
#1 xdo_new_with_opened_display (xdpy=, display=, close_display_when_freed=close_display_when_freed@entry=1) at xdo.c:133
#2 0x00007ffff7bd80a1 in xdo_new (display_name=, display_name@entry=0x0) at xdo.c:95
#3 0x000000000040319e in args_main (argc=argc@entry=4, argv=argv@entry=0x7fffffffe668) at xdotool.c:493
#4 0x0000000000403724 in xdotool_main (argc=4, argv=0x7fffffffe668) at xdotool.c:316

So we got an unhandled NULL coming from XkbGetMap() :-(

Xvnc version TightVNC-1.3.9
Linux xxxx 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
xdotool/libxd built minutes ago from HEAD.

input: xdotool search --pid <program_pid>
output Can't consume 1 args; are only 0 available. This is a bug.
version: xdotool version 2.20110530.1
system: Arch Linux (3.6.8-1-ARCH)
I wanted to use xdotool in a shell-script to wait for X applications to be visible. Therefore I issued a command like this:

xdotool search --onlyvisible --sync --pid 1234

The output was this: Can't consume 1 args; are only 0 available. This is a bug.

I narrowed down the issue to the --pid option, which causes the aforementioned error message.

Hi, maybe it's just that I don't understand something, but this seems to be quite broken.
Here is a script:

echo KP_Enter
xdotool key KP_Enter
echo "
"
echo KP_0
xdotool key KP_0
echo "
"
echo KP_1
xdotool key KP_1
echo "
"
echo KP_2
xdotool key KP_2
echo "
"
echo KP_3
xdotool key KP_3
echo "
"
echo KP_4
xdotool key KP_4
echo "
"
echo KP_5
xdotool key KP_5
echo "
"
echo KP_6
xdotool key KP_6
echo "
"
echo KP_7
xdotool key KP_7
echo "
"
echo KP_8
xdotool key KP_8
echo "
"
echo KP_9
xdotool key KP_9
echo "
"
echo KP_Insert
xdotool key KP_Insert
echo "
"
echo KP_Delete
xdotool key KP_Delete
echo "
"
echo KP_Add
xdotool key KP_Add
echo "
"
echo KP_Subtract
xdotool key KP_Subtract
echo "
"
echo KP_Divide
xdotool key KP_Divide
echo "
"
echo KP_Multiply
xdotool key KP_Multiply
echo "
"
echo KP_Home
xdotool key KP_Home
echo "
"
echo KP_Up
xdotool key KP_Up
echo "
"
echo KP_Prior
xdotool key KP_Prior
echo "
"
echo KP_Left
xdotool key KP_Left
echo "
"
echo KP_Tab
xdotool key KP_Tab
echo "
"
echo KP_Right
xdotool key KP_Right
echo "
"
echo KP_End
xdotool key KP_End
echo "
"
echo KP_Down
xdotool key KP_Down
echo "
"
echo KP_Next
xdotool key KP_Next

If I run the script with Num Lock on, this is what happens:

[root@archie ~]# sh /tmp/test_xdotool.sh
KP_Enter



KP_0
^[[2$

KP_1
^[[8$

KP_2
^[[b

KP_3
^[[6$

KP_4
^[[d

KP_5


KP_6
^[[c

KP_7
^[[7$

KP_8
^[[a

KP_9
^[[5$

KP_Insert
0

KP_Delete
.

KP_Add
+

KP_Subtract
-

KP_Divide
/

KP_Multiply
*

KP_Home
7

KP_Up
8

KP_Prior
9

KP_Left
4

KP_Tab


KP_Right
6

KP_End
1

KP_Down
2

KP_Next
3[root@archie ~]# 
[root@archie ~]# 0.+-/*78946123

If I run the script with Num Lock off, this is what happens:

[root@archie ~]# sh /tmp/test_xdotool.sh
KP_Enter



KP_0
^[Op

KP_1
^[Oq

KP_2
^[Or

KP_3
^[Os

KP_4
^[Ot

KP_5
^[Ou

KP_6
^[Ov

KP_7
^[Ow

KP_8
^[Ox

KP_9
^[Oy

KP_Insert
^[[2~

KP_Delete
^[[3~

KP_Add
+

KP_Subtract
-

KP_Divide
/

KP_Multiply
*

KP_Home
^[[7~

KP_Up
^[[A

KP_Prior
^[[5~

KP_Left
^[[D

KP_Tab


KP_Right
^[[C

KP_End
^[[8~

KP_Down
^[[B

KP_Next
^[[6~[root@archie ~]# 
(i-search)`': ^[[3~+-/*

xdotool crashes with a segmentation fault if the display is not reachable.

How to reproduce

unset DISPLAY
xdotool getmouselocation

; xdotool search --class xterm behave %@ focus getactivewindow
44040207
*** Error in `xdotool': double free or corruption (out): 0x00007fff40df9700 ***
zsh: abort      xdotool search --class xterm behave %@ focus getactivewindow
*

I presume this happens because search finds the same window that getactivewindow finds.

Executing

xdotool search --onlyvisible . behave %@ focus getactivewindow getwindowname

and then focusing a window causes the program to crash:

Defaulting to search window name, class, and classname
*** Error in `xdotool': double free or corruption (out): 0x00007ffd8f26d8a0 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x7198e)[0x7f82fc55f98e]
/usr/lib/libc.so.6(+0x76dee)[0x7f82fc564dee]
/usr/lib/libc.so.6(+0x775cb)[0x7f82fc5655cb]
xdotool[0x402c9a]
xdotool[0x406b85]
xdotool[0x40310b]
xdotool[0x407ed4]
xdotool[0x40310b]
xdotool[0x4033c7]
xdotool[0x4038f4]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7f82fc50e800]
xdotool[0x402b01]
======= Memory map: ========
00400000-0040f000 r-xp 00000000 08:03 275112                             /usr/bin/xdotool
0060e000-0060f000 r--p 0000e000 08:03 275112                             /usr/bin/xdotool
0060f000-00611000 rw-p 0000f000 08:03 275112                             /usr/bin/xdotool
00cdb000-00d5e000 rw-p 00000000 00:00 0                                  [heap]
7f82fb05f000-7f82fb075000 r-xp 00000000 08:03 269331                     /usr/lib/libgcc_s.so.1
7f82fb075000-7f82fb274000 ---p 00016000 08:03 269331                     /usr/lib/libgcc_s.so.1
7f82fb274000-7f82fb275000 rw-p 00015000 08:03 269331                     /usr/lib/libgcc_s.so.1
7f82fb275000-7f82fb27a000 r-xp 00000000 08:03 269292                     /usr/lib/libXdmcp.so.6.0.0
7f82fb27a000-7f82fb479000 ---p 00005000 08:03 269292                     /usr/lib/libXdmcp.so.6.0.0
7f82fb479000-7f82fb47a000 r--p 00004000 08:03 269292                     /usr/lib/libXdmcp.so.6.0.0
7f82fb47a000-7f82fb47b000 rw-p 00005000 08:03 269292                     /usr/lib/libXdmcp.so.6.0.0
7f82fb47b000-7f82fb47d000 r-xp 00000000 08:03 269286                     /usr/lib/libXau.so.6.0.0
7f82fb47d000-7f82fb67d000 ---p 00002000 08:03 269286                     /usr/lib/libXau.so.6.0.0
7f82fb67d000-7f82fb67e000 r--p 00002000 08:03 269286                     /usr/lib/libXau.so.6.0.0
7f82fb67e000-7f82fb67f000 rw-p 00003000 08:03 269286                     /usr/lib/libXau.so.6.0.0
7f82fb67f000-7f82fb68e000 r-xp 00000000 08:03 272554                     /usr/lib/libXi.so.6.1.0
7f82fb68e000-7f82fb88e000 ---p 0000f000 08:03 272554                     /usr/lib/libXi.so.6.1.0
7f82fb88e000-7f82fb88f000 r--p 0000f000 08:03 272554                     /usr/lib/libXi.so.6.1.0
7f82fb88f000-7f82fb890000 rw-p 00010000 08:03 272554                     /usr/lib/libXi.so.6.1.0
7f82fb890000-7f82fb8a1000 r-xp 00000000 08:03 269295                     /usr/lib/libXext.so.6.4.0
7f82fb8a1000-7f82fbaa0000 ---p 00011000 08:03 269295                     /usr/lib/libXext.so.6.4.0
7f82fbaa0000-7f82fbaa1000 r--p 00010000 08:03 269295                     /usr/lib/libXext.so.6.4.0
7f82fbaa1000-7f82fbaa2000 rw-p 00011000 08:03 269295                     /usr/lib/libXext.so.6.4.0
7f82fbaa2000-7f82fbaa4000 r-xp 00000000 08:03 268241                     /usr/lib/libdl-2.21.so
7f82fbaa4000-7f82fbca4000 ---p 00002000 08:03 268241                     /usr/lib/libdl-2.21.so
7f82fbca4000-7f82fbca5000 r--p 00002000 08:03 268241                     /usr/lib/libdl-2.21.so
7f82fbca5000-7f82fbca6000 rw-p 00003000 08:03 268241                     /usr/lib/libdl-2.21.so
7f82fbca6000-7f82fbcc7000 r-xp 00000000 08:03 270129                     /usr/lib/libxcb.so.1.1.0
7f82fbcc7000-7f82fbec6000 ---p 00021000 08:03 270129                     /usr/lib/libxcb.so.1.1.0
7f82fbec6000-7f82fbec7000 r--p 00020000 08:03 270129                     /usr/lib/libxcb.so.1.1.0
7f82fbec7000-7f82fbec8000 rw-p 00021000 08:03 270129                     /usr/lib/libxcb.so.1.1.0
7f82fbec8000-7f82fbee0000 r-xp 00000000 08:03 268232                     /usr/lib/libpthread-2.21.so
7f82fbee0000-7f82fc0df000 ---p 00018000 08:03 268232                     /usr/lib/libpthread-2.21.so
7f82fc0df000-7f82fc0e0000 r--p 00017000 08:03 268232                     /usr/lib/libpthread-2.21.so
7f82fc0e0000-7f82fc0e1000 rw-p 00018000 08:03 268232                     /usr/lib/libpthread-2.21.so
7f82fc0e1000-7f82fc0e5000 rw-p 00000000 00:00 0 
7f82fc0e5000-7f82fc0e7000 r-xp 00000000 08:03 272557                     /usr/lib/libXinerama.so.1.0.0
7f82fc0e7000-7f82fc2e6000 ---p 00002000 08:03 272557                     /usr/lib/libXinerama.so.1.0.0
7f82fc2e6000-7f82fc2e7000 r--p 00001000 08:03 272557                     /usr/lib/libXinerama.so.1.0.0
7f82fc2e7000-7f82fc2e8000 rw-p 00002000 08:03 272557                     /usr/lib/libXinerama.so.1.0.0
7f82fc2e8000-7f82fc2ed000 r-xp 00000000 08:03 272566                     /usr/lib/libXtst.so.6.1.0
7f82fc2ed000-7f82fc4ec000 ---p 00005000 08:03 272566                     /usr/lib/libXtst.so.6.1.0
7f82fc4ec000-7f82fc4ed000 r--p 00004000 08:03 272566                     /usr/lib/libXtst.so.6.1.0
7f82fc4ed000-7f82fc4ee000 rw-p 00005000 08:03 272566                     /usr/lib/libXtst.so.6.1.0
7f82fc4ee000-7f82fc687000 r-xp 00000000 08:03 268212                     /usr/lib/libc-2.21.so
7f82fc687000-7f82fc887000 ---p 00199000 08:03 268212                     /usr/lib/libc-2.21.so
7f82fc887000-7f82fc88b000 r--p 00199000 08:03 268212                     /usr/lib/libc-2.21.so
7f82fc88b000-7f82fc88d000 rw-p 0019d000 08:03 268212                     /usr/lib/libc-2.21.so
7f82fc88d000-7f82fc891000 rw-p 00000000 00:00 0 
7f82fc891000-7f82fc9cc000 r-xp 00000000 08:03 263643                     /usr/lib/libX11.so.6.3.0
7f82fc9cc000-7f82fcbcb000 ---p 0013b000 08:03 263643                     /usr/lib/libX11.so.6.3.0
7f82fcbcb000-7f82fcbcd000 r--p 0013a000 08:03 263643                     /usr/lib/libX11.so.6.3.0
7f82fcbcd000-7f82fcbd2000 rw-p 0013c000 08:03 263643                     /usr/lib/libX11.so.6.3.0
7f82fcbd2000-7f82fcbd3000 rw-p 00000000 00:00 0 
7f82fcbd3000-7f82fcbda000 r-xp 00000000 08:03 268233                     /usr/lib/librt-2.21.so
7f82fcbda000-7f82fcdd9000 ---p 00007000 08:03 268233                     /usr/lib/librt-2.21.so
7f82fcdd9000-7f82fcdda000 r--p 00006000 08:03 268233                     /usr/lib/librt-2.21.so
7f82fcdda000-7f82fcddb000 rw-p 00007000 08:03 268233                     /usr/lib/librt-2.21.so
7f82fcddb000-7f82fcede000 r-xp 00000000 08:03 268258                     /usr/lib/libm-2.21.so
7f82fcede000-7f82fd0de000 ---p 00103000 08:03 268258                     /usr/lib/libm-2.21.so
7f82fd0de000-7f82fd0df000 r--p 00103000 08:03 268258                     /usr/lib/libm-2.21.so
7f82fd0df000-7f82fd0e0000 rw-p 00104000 08:03 268258                     /usr/lib/libm-2.21.so
7f82fd0e0000-7f82fd0eb000 r-xp 00000000 08:03 275114                     /usr/lib/libxdo.so.2
7f82fd0eb000-7f82fd2ea000 ---p 0000b000 08:03 275114                     /usr/lib/libxdo.so.2
7f82fd2ea000-7f82fd2eb000 r--p 0000a000 08:03 275114                     /usr/lib/libxdo.so.2
7f82fd2eb000-7f82fd2ec000 rw-p 0000b000 08:03 275114                     /usr/lib/libxdo.so.2
7f82fd2ec000-7f82fd30e000 r-xp 00000000 08:03 268254                     /usr/lib/ld-2.21.so
7f82fd4d6000-7f82fd4de000 rw-p 00000000 00:00 0 
7f82fd50c000-7f82fd50d000 rw-p 00000000 00:00 0 
7f82fd50d000-7f82fd50e000 r--p 00021000 08:03 268254                     /usr/lib/ld-2.21.so
7f82fd50e000-7f82fd50f000 rw-p 00022000 08:03 268254                     /usr/lib/ld-2.21.so
7f82fd50f000-7f82fd510000 rw-p 00000000 00:00 0 
7ffd8f24e000-7ffd8f26f000 rw-p 00000000 00:00 0                          [stack]
7ffd8f308000-7ffd8f30a000 r--p 00000000 00:00 0                          [vvar]
7ffd8f30a000-7ffd8f30c000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted (core dumped)

While fixing bugs found with Clang static analyzer, I encountered the cmd_behave_screen_edge function.

Issues that make me avoid fixing this code:

• printf debugging prints
• duplication of timer code with
• no comments describing what the timer code is used for.

The actual issue was a "Dead assignment" warning, in cmd_behave_screen_edge.c:295. Variable trigger is set to False every time the loop is executed.

Another question: why is need_new_context = True written on line 294? context_execute does not seem to free tmpcontext. Perhaps the tmpcontext = calloc(..) part should be moved outside the while loop and the copy be made unconditional? I don't know... I am not using this option and I am not going to fix it either.

Hi!

I'm newbie at using xdotool and I was trying to do the following in my Centos 6.5, xdotool (xdotool-2.20110530.1-7.el6.x86_64), kernel 2.6.32, xorg-x11-server-Xorg-1.13.0-23.1.el6.centos.x86_64:

I opened a PuTTY terminal and execute an xterm to open a new terminal xterm &
Then I get the ID of this new terminal with xdotool search --name "myterminal"
Finally I execute xdotool key --window "ID" 2 to send a 2 to the terminal but nothing happens.
I checked also the ID of the terminal with xwinfo

I used it with windowfocus and windowsactivate, but I'd like to avoid it if possible. Also, is there any possibility of speeding the process, everytime that I send an keystroke, the execution of the command xdotool key 2 line is quite slow for my purposes.

I want to open as several terminals and then send them a chain of keystroke as fast as possible with some delay between keystrokes.

I also have another issue, having my little script xdotool

!/usr/bin/xdotool

windowfocus $1
type "Hi, how are you"
key 7

It doesn't press number 7 after typing Hi, how are you, it types Hi, how are youkey 7. How can I solve it?

Thank you very much, sorry but I'm a newbie!

Hi, I want to run a command xdotool key enter, but I get error like this:

(symbol) No such key name 'enter'. Ignoring it.

So. I would like to know whether there is an "enter" key?

I came across this post that windowclose patch was integrated, but the command still isn't available--at least in my version of xdotool.

Google Group: Close a Window

$ xdotool -v
xdotool version 3.20130505.1

When doing a type with the --file argument, some characters are replaced. In my test case, _ is replaced by ?, ' by / and + by -.

I'm running i3 in Arch. Also documented here. Thanks for the great tool!

$ xinput
⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ bcm5974                                   id=11   [slave  pointer  (2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard (3)]
    ↳ Power Button                                id=6    [slave  keyboard (3)]
    ↳ Video Bus                                   id=7    [slave  keyboard (3)]
    ↳ Power Button                                id=8    [slave  keyboard (3)]
    ↳ Sleep Button                                id=9    [slave  keyboard (3)]
    ↳ Apple Inc. Apple Internal Keyboard / Trackpad   id=10   [slave  keyboard (3)]
$ xkbcomp -i 3 keymap.xkb :0
$ xdotool type "bla"
bla⏎               

keymap.xkb is no longer active after running the commands above.

windowsize accepts percentages of the screen--it would be good if windowmove did too, so I could e.g. set up windows in the four quadrants easily.

Note that the formula should make placements of, for example, 33.33% or 50% width and similar X position work out to tile the screen with no overlap.

I think the correct formula is simply to round down and make no adjustment (the default)

On my 3 monitor system running openbox, getdisplaygeometry and getmouselocation always return data for screen 0, even when the active screen is not screen 0.

There should be git tags for previous releases, so people can do stuff like

git log v2.20110530.1..HEAD

to see what they're getting by switching to using a git checkout.

I already figured out that v2.20110530.1 corresponds to 15835e3 but didn't look at older releases.

Hi,
if I start the program with ' xdotool - ' , the program does not execute the commands that I put in following lines. I'm missing something or this feature is broken?

Stefano

I am unable to send braces {} and brackets [] using type:

Calling

xdotool type --window 73400333 'a[]b{}'

inside an xterm, gives "ab" in another xterm with the above id.

xdotool type 'a[]b{}'

yields "aeib.p" in the very same window.

I ZIP'd the latest code, and modified the makefile:
DEFAULT_LIBS=-L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -lX11 -lXtst -lXinerama

DEFAULT_LIBS=-L/usr/X11R6/lib -L/usr/local/lib -lX11 -lXtst -lXinerama

since Xtst is under /usr/lib
/usr/lib/libXtst.so.6
/usr/lib/libXtst.so.6.1.0
/usr/lib64/libXtst.so.6
/usr/lib64/libXtst.so.6.1.0

I tried to compile, but get:
pod2man -c "" -r "" xdotool.pod > xdotool.1
sh version.sh --header > xdo_version.h
cc -pipe -O2 -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization -Wno-missing-field-initializers -g -std=c99 -I/usr/X11R6/include -I/usr/local/include -fPIC -c xdo.c
cc -pipe -O2 -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization -Wno-missing-field-initializers -g -std=c99 -I/usr/X11R6/include -I/usr/local/include -fPIC -c xdo_search.c
cc -shared -Wl,-soname=libxdo.so.2 xdo.o xdo_search.o -o libxdo.so -lrt -L/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -lX11 -lXtst -lXinerama
/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/libX11.so when searching for -lX11
/usr/bin/ld: cannot find -lXtst
collect2: ld returned 1 exit status
make: *** [libxdo.so] Error 1

Any suggestions?

Thanks.

Lester

P.S.:

I also could not compile on Ubuntu 12.04:
pod2man -c "" -r "" xdotool.pod > xdotool.1
sh version.sh --header > xdo_version.h
cc -pipe -O2 -pedantic -Wall -W -Wundef -Wendif-labels -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wdisabled-optimization -Wno-missing-field-initializers -g -std=c99 -I/usr/X11R6/include -I/usr/local/include -fPIC -c xdo.c
xdo.c:29:34: fatal error: X11/extensions/XTest.h: No such file or directory
compilation terminated.
make: *** [xdo.o] Error 1