Command chaining is broken

[lahwaacz]

Basic chaining works fine:

$ xdotool search --class MuPDF getwindowname
command-line.pdf - 1/169 (102 dpi)

But the -- separator mentioned in the man page is not recognized:

$ xdotool search --class MuPDF -- getwindowname
xdotool: Unknown command: --
Run 'xdotool help' if you want a command list

Moreover, if you use the type subcommand, it consumes all the remaining command line arguments and "types" them to the window. It should only take one argument, spaces can be escaped from the shell.

xdotool version 3.20150503.1-1 in Arch Linux

[katanacrimson]

May be PEBKAC on my part, but I believe this to be another example of the issue:

xdotool search --pid "$pid" windowmove %@ ${dims[2]} ${dims[3]} windowsize %@ ${dims[0]} ${dims[1]}

xdotool then chokes upon the %@ after windowmove, apparently expecting a window ID param even though --pid only was providing one window ID.

[lahwaacz]

Let's take basic test:

$ xdotool search --class tinyterm
14680065
25165825
27262977
29360129

Let's see if window stack works:

$ xdotool search --class tinyterm getwindowname %1
tinyterm
$ xdotool search --class tinyterm getwindowname %2
tinyterm
$ xdotool search --class tinyterm getwindowname %@
tinyterm
tinyterm
tinyterm
tinyterm

Everything seems OK. Let's have a look at --pid:

$ xdotool search --pid 1833
41943041
41943105
41943043

No idea why there are 3 windows for this PID, but well...

$ xdotool search --pid 1833 getwindowname
Defaulting to search window name, class, and classname
41943041
41943105
41943043

What does this message mean? And where are the window names? Let's specify %1, which is the default, but just in case:

 $ xdotool search --pid 1833 getwindowname %1
Defaulting to search window name, class, and classname
xdotool: Unknown command: %1
Run 'xdotool help' if you want a command list

This is the same error as if xdotool getwindowname %1 were run without search, in which case the window stack is empty. So I guess the results of search --pid do not end up on the stack at all, which is not related to the chaining, but it is still a mighty bug.

[bdowling]

This to me looks like a side effect of xdotool not having a consistent way to separate commands in a chain, which makes it hard to parse the arg list. In this case it is swallowing up the next command as the search criteria, as if there are more args to process and if you don't specify a --name, --class or --classname it'll spit out that error message to search all three (and swallow up the next arg). So if you are searching by --pid, you can do something like this as a workaround:

xdotool search --all --pid 3037 --class '.'  getwindowname  '%@'

It might be nice if '--' or something similar (maybe ; )was used to separate the commands in a chain. I've seen this listed in some examples, but given the above I don't think it has the effect some people thought.

[bdowling]

First time looking at this code, but perhaps this test could also be changed to fix this:

xdotool/cmd_search.c

Line 150 in c869b75

if (context->argc > 0) {

To:

if (context->argc > 0 && search.pid == 0)

e.g. if --pid was specified, don't make any assumptions and swallow up another argument.

[bdowling]

fwiw this is mostly a duplicate of #14 as well. It's a bit more involved than the fix I suggested above, I'll give it a go and submit a pull if I can fix this.

I've got the same type of problem (and it makes trying to get KeePass autotyping to work even harder than it is already).

xdotool search --all --class gedit --classname k

generates no error. Yet,

xdotool search --all --class k --classname e

does.

[jordansissel]

It's confusing, but the --class and --classname options are flags to tell the search system what you want to search for. The flags take no arguments.

I regret making this interface choice because it is confusing, but I can at least try to explain how to use it.

When you specify xdotool search --class foo you are saying "Search for ll windows for the string foo, but only look at the class.` The flag chooses what window properties to search, it does not set what value for a property to search.

In this way, --class gedit --classname k is probably not valid (I haven't tested) because I'm not sure what xdotool is expected to do. To translate to english, roughly, this says Search the window properties "class" and "classname" for the string "gedit"

[adokitkat]

this is still broken

[osirisgothra]

Yes it is

This comment is for those who run into this problem. After 20 years of reporting bugs and never having any response, I just stopped doing it.

xdotool search --all --class xfce4-panel search --name Question
xdotool search --all --class xfce4-panel -- --name Question
xdotool search --all --class xfce4-panel [tried --classname, even --pid example] --name Question

The first one works, but matches any instead of all, even if you add --all to the second search, my understanding that this isn't the right way to do it, as they are separate but...

The second one, from the docs, seems to be the 'appropriate way' to do things, except it doesn't work on search. The -- is seen as an error.

The final one, from my current docs, suggest command chaining will search for windows by class then those results by name. This does not happen. My final guess is "command chaining" does not support the search command.

This works:

xdotool search --all --pid 1424 --name "Hello World"

THE REASON / STEPS TO REPRODUCE

EDIT: rewriting this section as there is a VERY WEIRD bug and its not the number or the dash, but seems to be related:

Works: xdotool search [--all] --class xfce-panel --name xfce
Not???: xdotool search --class xfcepanel --name xfce
Not???: xdotool search --class xfce4 --name xfce
Works: xdotool search [--all] --class xfce-panel --name xfce
Works: xdotool search --all --class axfce --name xfce
Not???: xdotool search --all --class xfce --name xfce

That is some WEIRD behavior. As you can see there seems to be some subtle bug somewhere.

WORKAROUND

Can't seem to find one as there is no real way to predict what is offensive and what isnt to the program. For now, piping is the best we can do:

xdotool search --all --name Question | grep -P "$(xdotool search --all --class terminology | tr '\n' '|' )"

[jordansissel]

There is a proposal in #357 to make a new command that works the way most folks expect - #357 (comment)