Buggy behaviour for "xdotool search --pid <pid>"

[tuffnerdstuff]

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.

[lemzwerg]

I got exactly the same problem. Given the usefulness of this option, I would value this as a high-priority bug.

[worenga]

A workaround seems to be to also provide the --name parameter for the given pid

[jordansissel]

I'll see what I can do.

[jordansissel]

Searching by pid works for me on master:

% ./xdotool search --pid 2593
Can't consume 1 args; are only 0 available. This is a bug.
54525953
54527731
54525955

The only bug is that it warns you about consuming args. I'll fix that.

[jordansissel]

Fixed the warning! :)

[javierabreu]

Ubuntu Gnome 14.04
xdotool version 3.20140217.1
Bug is still present

xdotool search --pid 7558
Can't consume 1 args; are only 0 available. This is a bug.

Ugly workaround:

xdotool search --any --pid 7558 --name "dummy_name_bug_workaround_1gqbvy4o5y8bw3ov5"

[aboettger]

This is a distribution-specific problem. The latest version on GitHub works.

[PlasmaPower]

It seems to still happen to some degree in the latest version. Example:

$ xdotool version
xdotool version 3.20150503.1
$ xdotool search --pid $$
$ xdotool search --any --pid $$ --name "nonexistantname"
48234503

[cosmoharrigan]

Search by process ID does not work with the latest version:

$ xdotool --version
xdotool version 3.20160112.1

[hilbix]

$ ./xdotool.static version
xdotool version 3.20161220.1

search --pid still has a bug. Just muting the warning about the bug does not make the bug go away.

$ ./xdotool.static search --onlyvisible --pid 31981 windowactivate %@
Defaulting to search window name, class, and classname
./xdotool.static: Unknown command: %@
Run './xdotool.static help' if you want a command list
$

does nothing, while

$ ./xdotool.static search --any --onlyvisible --pid 31981 --name "this_window_name_does_not_exist_sqr13rkckf_this_window_name_does_not_exist_sqr13rkckf_this_window_name_does_not_exist_sqr13rkckf_this_window_name_does_not_exist_sqr13rkckf_this_window_name_does_not_exist_sqr13rkckf" windowactivate %@
$

works as expected (and no output whatsoever and the window is activated).

To others: Please note that --pid needs the WindowManager option _NET_WM_PID to be set by the application, which is not the default. For more on this, see http://stackoverflow.com/a/13482052/490291

[anthonybakermpls]

anthony@bluegreen:~/Data/Code$ xdotool search --pid 15188
Segmentation fault (core dumped)

even if the _NET_WM_PID isn't set it would be nice if we didn't crash.

[Hibou57]

@javierabreu, there is a simpler work around, redirecting standard error to /dev/null: xdotool … 2>/dev/null.

[Hibou57]

By the way, there are other strange behaviours with options.

This one works:

search --all --onlyvisible --pid 23507 --class surf

This one does not work, complaining “xdotool: Unknown command: --pid”:

search --all --onlyvisible --class surf --pid 23507

[ipaqmaster]

Tried to search --pid 12345 with xdotool 3.20211022.1 today and while that works I've noticed if you pass additional arguments to do something with the resulting window, matched by pid, xdotool throws Defaulting to search window name, class, classname, and role instead of treating the --pid argument as a valid solo search parameter.

One shouldn't need to call a nested $(xdotool search --pid $(ps filter for pid by name)) as an argument to xdotool just to return a window ID it can action upon. --pid should be a valid searching parameter on its own.