Bug 602952 - F13 xdotool scripting scheme is problematic
Summary: F13 xdotool scripting scheme is problematic
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xdotool
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Sven Lankes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-11 05:56 UTC by Bruce Jerrick
Modified: 2010-12-05 19:57 UTC (History)
2 users (show)

Fixed In Version: xdotool-2.20101012.3049-1.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-05 19:57:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Two patches for xdotool. (3.22 KB, application/octet-stream)
2010-06-11 05:56 UTC, Bruce Jerrick
no flags Details

Description Bruce Jerrick 2010-06-11 05:56:31 UTC
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):
xdotool-1.20100227.2679-1.fc13.i686.rpm

How reproducible:
100%

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:

Actual results:
No output (xdotool is a silent no-op).

Expected results:
The normal report of a window ID, e.g.:
37748740

Additional info:
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
  xdotool-isatty.patch .

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
now.)

BTW, the shebang script mechanism (#!/usr/bin/xdotool) is rather inefficient
in that it invokes a new process for every command in the script.

Comment 1 Sven Lankes 2010-06-11 17:54:35 UTC
 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.

Comment 2 T-Gergely 2010-11-05 23:42:28 UTC
> 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.

Comment 3 Fedora Update System 2010-11-17 21:37:39 UTC
xdotool-2.20101012.3049-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/xdotool-2.20101012.3049-1.fc13

Comment 4 Fedora Update System 2010-11-19 00:14:29 UTC
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

Comment 5 Fedora Update System 2010-12-05 19:57:11 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.