Red Hat Bugzilla – Bug 602952
F13 xdotool scripting scheme is problematic
Last modified: 2010-12-05 14:57:15 EST
Created attachment 423149 [details]
Two patches for xdotool.
Description of problem(s):
The new scripting feature of F13 xdotool has introduced a couple of problems:
1. If xdotool is used in a context where stdin has been redirected (e.g., in
a backend shell script fed from a pipe), xdotool is a silent no-op.
2. If xdotool is invoked with single-argument commands (e.g.,
'xdotool getactivewindow') and a file happens to exist with that name
(getactivewindow), xdotool assumes it should read commands from that file.
Version-Release number of selected component (if applicable):
Steps to Reproduce problem #1:
1. echo "xdotool getactivewindow" > backend; chmod u+x backend
2. echo anything | ./backend
Steps to Reproduce problem #2:
1. cp /dev/null getactivewindow
2. xdotool getactivewindow
Results are the same for both problems:
No output (xdotool is a silent no-op).
The normal report of a window ID, e.g.:
Worse yet, if file 'getactivewindow' in the example above has any contents,
xdotool treats them as commands, and chaos could ensue.
Possible fixes follow. They introduce some command-line incompatibility,
but that is not nearly as disruptive as the current breakage of pipe-fed
backends using xdotool.
(The two patches mentioned below are in one attachment, with an obvious
separator; Mr. Bugzilla apparently won't let me attach two files.)
Problem #1 can be solved by eliminating the !isatty(0) tests in xdotool.c .
That would preclude the 'xdotool < myfile' form, but it's not really needed;
one can use 'xdotool - < myfile' instead.
I have included a patch for this (xdotool-isatty.patch) as an attachment.
Problem #2 can be solved by eliminating the stat() test in xdotool.c .
That would require a different mechanism to handle shebang (#!) scripts;
one possibility is to add support for a '-f script' option, and require a
'-f' option on the shebang header; e.g., "#!/usr/bin/xdotool -f" (as in
the old days).
Then instead of 'xdotool filename' one would have to use either
'xdotool -f filename' or 'xdotool - < filename'.
I have included a patch for this (xdotool-dont-read-from-command-names.patch)
as an attachment. The patch context assumes the application of
If fixes are not implemented, a BUGS section should be added to 'man xdotool'
warning about these conditions. (The good news is that there's a man page
BTW, the shebang script mechanism (#!/usr/bin/xdotool) is rather inefficient
in that it invokes a new process for every command in the script.
Issues like this are really much better kept in the upstream bug-tracker.
Could you please file this with $UPSTREAM @ http://code.google.com/p/semicomplete/issues/list ?
I could file it but then I would have to be the man in the middle for all following discussion.
> Could you please file this with $UPSTREAM @
> http://code.google.com/p/semicomplete/issues/list ?
Problem #1 (which I do care about as I used xdotool as a cross-user screensaver inhibitor in Fedora 12, and now it fails) seems to had been fixed upstream (http://code.google.com/p/semicomplete/issues/detail?id=19&can=1&q=xdotool).
Please, pack the fixed version.
xdotool-2.20101012.3049-1.fc13 has been submitted as an update for Fedora 13.
xdotool-2.20101012.3049-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update xdotool'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/xdotool-2.20101012.3049-1.fc13
xdotool-2.20101012.3049-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.