neulab/tldr huggingface dataset:
Common: agent The puppet agent daemon apply Apply Puppet manifests locally config Interact with Puppet´s settings. help Display Puppet help. lookup Interactive Hiera lookup module Creates, installs and searches for modules on the Puppet Forge. resource The resource abstraction layer shell
Specialized: catalog Compile, save, view, and convert catalogs. describe Display help about resource types device Manage remote network devices doc Generate Puppet references epp Interact directly with the EPP template parser/renderer. facts Retrieve and store facts. filebucket Store and retrieve files in a filebucket generate Generates Puppet code from Ruby definitions. node View and manage node definitions. parser Interact directly with the parser. plugin Interact with the Puppet plugin system. script Run a puppet manifests as a script without compiling a catalog ssl Manage SSL keys and certificates for puppet SSL clients
See ´puppet help subcommand action´ for help on a specific subcommand action. See ´puppet help subcommand´ for help on a specific subcommand. Puppet v7.12.1
COLRM(1)                          User Commands                         COLRM(1)
colrm - remove columns from a file
colrm [first [last]]
colrm removes selected columns from a file. Input is taken from standard input. Output is sent to standard output.
If called with one parameter the columns of each line will be removed starting with the specified first column. If called with two parameters the columns from the first column to the last column will be removed.
Column numbering starts with column 1.
The colrm command appeared in 3.0BSD.
awk(1p), column(1), expand(1), paste(1)
The colrm command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.
XDOTOOL(1)                                                            XDOTOOL(1)
xdotool - command-line X11 automation tool
xdotool cmd args...
Notation: Some documentation uses [window] to denote an optional window argument. This case means that the argument, if not present, will default to "%1". See "WINDOW STACK" for what "%1" means.
xdotool lets you programmatically (or manually) simulate keyboard input and mouse activity, move and resize windows, etc. It does this using X11's XTEST extension and other Xlib functions.
There is some support for Extended Window Manager Hints (aka EWMH or NetWM).  See the "EXTENDED WINDOW MANAGER HINTS" section for more information.
key [options] keystroke [keystroke ...] Options:
--window window Send keystrokes to a specific window id. You can use "WINDOW STACK" references like "%1" and "%@" here. If there is a window stack, then "%1" is the default, otherwise the current window is used.
See also: "SENDEVENT NOTES" and "WINDOW STACK"
--clearmodifiers Clear modifiers before sending keystrokes. See CLEARMODIFIERS below.
--delay milliseconds Delay between keystrokes. Default is 12ms.
Type a given keystroke. Examples being "alt+r", "Control_L+J", "ctrl+alt+n", "BackSpace".
Generally, any valid X Keysym string will work. Multiple keys are separated by '+'. Aliases exist for "alt", "ctrl", "shift", "super", and "meta" which all map to Foo_L, such as Alt_L and Control_L, etc.
In cases where your keyboard doesn't actually have the key you want to type, xdotool will automatically find an unused keycode and use that to type the key.
With respect to "COMMAND CHAINING", this command consumes the remainder of the arguments or until a new xdotool command is seen, because no xdotool commands are valid keystrokes.
Example: Send the keystroke "F2" xdotool key F2
Example: Send 'a' with an accent over it (not on English keyboards, but still works with xdotool) xdotool key Aacute
Example: Send ctrl+l and then BackSpace as separate keystrokes: xdotool key ctrl+l BackSpace
Example: Send ctrl+c to all windows matching title 'gdb' (See "COMMAND CHAINING") xdotool search --name gdb key ctrl+c
keydown [options] keystroke Same as above, except only keydown (press) events are sent.
keyup keystroke Same as above, except only keyup (release) events are sent.
type [options] something to type Options:
--window windowid Send keystrokes to a specific window id. See "SENDEVENT NOTES" below. The default, if no window is given, depends on the window stack. If the window stack is empty the current window is typed at using XTEST. Otherwise, the default is "%1" (see "WINDOW STACK").
Types as if you had typed it. Supports newlines and tabs (ASCII newline and tab). Each keystroke is separated by a delay given by the --delay option.
With respect to "COMMAND CHAINING", this command consumes the remainder of the arguments and types them. That is, no commands can chain after 'type'.
Example: to type 'Hello world!' you would do: xdotool type 'Hello world!'
mousemove [options] x y OR 'restore' Move the mouse to the specific X and Y coordinates on the screen.
You can move the mouse to the previous location if you specify 'restore' instead of an X and Y coordinate. Restoring only works if you have moved previously in this same command invocation. Further, it does not work with the --window option.
For example, to click the top-left corner of the screen and move the mouse to the original position before you moved it, use this: xdotool mousemove 0 0 click 1 mousemove restore
--window WINDOW Specify a window to move relative to. Coordinates 0,0 are at the top left of the window you choose.
"WINDOW STACK" references are valid here, such as %1 and %@. Though, using %@ probably doesn't make sense.
--screen SCREEN Move the mouse to the specified screen to move to. This is only useful if you have multiple screens and ARE NOT using Xinerama.
The default is the current screen. If you specify --window, the --screen flag is ignored.
--polar Use polar coordinates. This makes 'x' an angle (in degrees, 0-360, etc) and 'y' the distance.
Rotation starts at 'up' (0 degrees) and rotates clockwise: 90 = right, 180 = down, 270 = left.
The origin defaults to the center of the current screen. If you specify a --window, then the origin is the center of that window.
--clearmodifiers See CLEARMODIFIERS
--sync After sending the mouse move request, wait until the mouse is actually moved. If no movement is necessary, we will not wait. This is useful for scripts that depend on actions being completed before moving on.
Note: We wait until the mouse moves at all, not necessarily that it actually reaches your intended destination. Some applications lock the mouse cursor to certain regions of the screen, so waiting for any movement is better in the general case than waiting for a specific target.
mousemove_relative [options] x y Move the mouse x,y pixels relative to the current position of the mouse cursor.
Note that we wait until the mouse moves at all, not necessarily that it actually reaches your intended destination. Some applications lock the mouse cursor to certain regions of the screen, so waiting for any movement is better in the general case than waiting for a specific target.
click [options] button Send a click, that is, a mousedown followed by mouseup for the given button with a short delay between the two (currently 12ms).
Buttons generally map this way: Left mouse is 1, middle is 2, right is 3, wheel up is 4, wheel down is 5.
--clearmodifiers Clear modifiers before clicking. See CLEARMODIFIERS below.
--repeat REPEAT Specify how many times to click. Default is 1. For a double- click, use '--repeat 2'
--delay MILLISECONDS Specify how long, in milliseconds, to delay between clicks. This option is not used if the --repeat flag is set to 1 (default).
--window WINDOW Specify a window to send a click to. See "SENDEVENT NOTES" below for caveats. Uses the current mouse position when generating the event.
The default, if no window is given, depends on the window stack. If the window stack is empty the current window is typed at using XTEST. Otherwise, the default is "%1" (see "WINDOW STACK").
mousedown [options] button Same as click, except only a mouse down is sent.
mouseup [options] button Same as click, except only a mouse up is sent.
getmouselocation [--shell] Outputs the x, y, screen, and window id of the mouse cursor. Screen numbers will be nonzero if you have multiple monitors and are not using Xinerama.
This command updates the window stack with the window id of the window directly underneath the mouse.
--shell This makes getmouselocation output shell data you can eval. Example:
% xdotool getmouselocation --shell X=880 Y=443 SCREEN=0 WINDOW=16777250
% eval $(xdotool getmouselocation --shell) % echo $X,$Y 714,324
behave_screen_edge [options] where command ... Bind an action to events when the mouse hits the screen edge or corner.
--delay MILLISECONDS Delay in milliseconds before running the command. This allows you to require a given edge or corner to be held for a short period before your command will run. If you leave the edge or corner before the delay expires then the time will reset.
--quiesce MILLISECONDS Delay in milliseconds before the next command will run. This helps prevent accidentally running your command extra times; especially useful if you have a very short --delay (like the default of 0).
* Mouse hits an edge or corner. * If delay is nonzero, the mouse must stay in this edge or corner until delay time expires. * If still in the edge/corner, trigger. * If quiesce is nonzero, then there is a cool-down period where the next trigger cannot occur
Valid 'where' values are:
left top-left top top-right right bottom-left bottom bottom-right
Examples: # Activate google-chrome when you move the mouse to the bottom-left corner: xdotool behave_screen_edge bottom-left \ search --class google-chrome windowactivate
# Go to the next workspace (right). Known to work in GNOME (metacity and compiz) xdotool behave_screen_edge --delay 500 bottom-right key XF86Forward
# Activate firefox and do a web search in a new tab for text in your clipboard xdotool behave_screen_edge --delay 1000 top-left \ search --classname Navigator \ windowactivate --sync key --delay 250 ctrl+t ctrl+k ctrl+v Return
search [options] pattern Search for windows with titles, names, or classes with a regular expression pattern. The output is line-delimited list of X window identifiers. If you are using "COMMAND CHAINING", the search command will only write window ids to stdout if it is the last (or only) command in the chain; otherwise, it is silent.
The result is saved to the window stack for future chained commands. See "WINDOW STACK" and "COMMAND CHAINING" for details.
Patterns are POSIX extended regular expressions (ERE), e. g. "Chrom(e|ium)$" for windows ending in "Chrome" or "Chromium". See regex(7) for syntax details.  Matches are case-insensitive.
The default options are "--name --class --classname --role" (unless you specify one or more of --name, --class, --classname, or --role).
The options available are:
--class Match against the window class.
--classname Match against the window classname.
--role Match against the window role.
--maxdepth N Set recursion/child search depth. Default is -1, meaning infinite. 0 means no depth, only root windows will be searched. If you only want toplevel windows, set maxdepth of 1 (or 2, depending on how your window manager does decorations).
--name Match against the window name. This is the same string that is displayed in the window titlebar.
--onlyvisible Show only visible windows in the results. This means ones with map state IsViewable.
--pid PID Match windows that belong to a specific process id. This may not work for some X applications that do not set this metadata on its windows.
--screen N Select windows only on a specific screen. Default is to search all screens. Only meaningful if you have multiple displays and are not using Xinerama.
--desktop N Only match windows on a certain desktop. 'N' is a number. The default is to search all desktops.
--limit N Stop searching after finding N matching windows. Specifying a limit will help speed up your search if you only want a few results.
The default is no search limit (which is equivalent to '--limit 0')
--title DEPRECATED. See --name.
--all Require that all conditions be met. For example:
xdotool search --all --pid 1424 --name "Hello World"
This will match only windows that have "Hello World" as a name and are owned by pid 1424.
--any Match windows that match any condition (logically, 'or'). This is on by default. For example:
xdotool search --any --pid 1424 --name "Hello World"
This will match any windows owned by pid 1424 or windows with name "Hello World"
--sync Block until there are results. This is useful when you are launching an application and want to wait until the application window is visible.  For example:
google-chrome & xdotool search --sync --onlyvisible --class "google-chrome"
selectwindow Get the window id (for a client) by clicking on it. Useful for having scripts query you humans for what window to act on. For example, killing a window by clicking on it:
xdotool selectwindow windowkill
behave window action command ... Bind an action to an event on a window. This lets you run additional xdotool commands whenever a matched event occurs.
The command run as a result of the behavior is run with %1 being the window that was acted upon. Examples follow after the event list.
The following are valid events:
mouse-enter Fires when the mouse enters a window. This is similar to 'mouse over' events in javascript, if that helps.
mouse-leave Fires when the mouse leaves a window. This is the opposite of 'mouse-enter'
mouse-click Fires when the mouse is clicked. Specifically, when the mouse button is released.
focus Fires when the window gets input focus.
blur Fires when the window loses focus.
# Print the cursor location whenever the mouse enters a currently-visible # window: xdotool search --onlyvisible . behave %@ mouse-enter getmouselocation
# Print the window title and pid whenever an xterm gets focus xdotool search --class xterm behave %@ focus getwindowname getwindowpid
# Emulate focus-follows-mouse xdotool search . behave %@ mouse-enter windowfocus
getwindowpid [window] Output the PID owning a given window. This requires effort from the application owning a window and may not work for all windows. This uses _NET_WM_PID property of the window. See "EXTENDED WINDOW MANAGER HINTS" below for more information.
If no window is given, the default is '%1'. If no windows are on the stack, then this is an error. See "WINDOW STACK" for more details.
Example: Find the PID for all xterms: xdotool search --class xterm getwindowpid %@
getwindowname [window] Output the name of a given window, also known as the title. This is the text displayed in the window's titlebar by your window manager.
getwindowgeometry [options] [window] Output the geometry (location and position) of a window. The values include: x, y, width, height, and screen number.
--shell Output values suitable for 'eval' in a shell.
getwindowfocus [-f] Prints the window id of the currently focused window. Saves the result to the window stack. See "WINDOW STACK" for more details.
If the current window has no WM_CLASS property, we assume it is not a normal top-level window and traverse up the parents until we find a window with a WM_CLASS set and return that window id.
If you really want the window currently having focus and don't care if it has a WM_CLASS setting, then use 'getwindowfocus -f'
windowsize [options] [window] width height Set the window size of the given window. If no window is given, %1 is the default.  See "WINDOW STACK" and "COMMAND CHAINING" for more details.
Percentages are valid for width and height. They are relative to the geometry of the screen the window is on. For example, to make a window the full width of the screen, but half height:
xdotool windowsize I<window> 100% 50%
Percentages are valid with --usehints and still mean pixel-width relative to the screen size.
--usehints Use window sizing hints (when available) to set width and height. This is useful on terminals for setting the size based on row/column of text rather than pixels.
--sync After sending the window size request, wait until the window is actually resized. If no change is necessary, we will not wait. This is useful for scripts that depend on actions being completed before moving on.
Note: Because many window managers may ignore or alter the original resize request, we will wait until the size changes from its original size, not necessary to the requested size.
Example: To set a terminal to be 80x24 characters, you would use: xdotool windowsize --usehints some_windowid 80 24
windowmove [options] [window] x y Move the window to the given position. If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
If the given x coordinate is literally 'x', then the window's current x position will be unchanged. The same applies for 'y'.
xdotool getactivewindow windowmove 100 100    # Moves to 100,100 xdotool getactivewindow windowmove x 100      # Moves to x,100 xdotool getactivewindow windowmove 100 y      # Moves to 100,y xdotool getactivewindow windowmove 100 y      # Moves to 100,y
xdotool windowmove I<window> 100% 50%
--sync After sending the window move request, wait until the window is actually moved. If no movement is necessary, we will not wait. This is useful for scripts that depend on actions being completed before moving on.
--relative Make movement relative to the current window position.
windowfocus [options] [window] Focus a window. If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
Uses XSetInputFocus which may be ignored by some window managers or programs.
--sync After sending the window focus request, wait until the window is actually focused. This is useful for scripts that depend on actions being completed before moving on.
windowmap [options] [window] Map a window. In X11 terminology, mapping a window means making it visible on the screen. If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
--sync After requesting the window map, wait until the window is actually mapped (visible). This is useful for scripts that depend on actions being completed before moving on.
windowminimize [options] [window] Minimize a window. In X11 terminology, this is called 'iconify.'  If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
--sync After requesting the window minimize, wait until the window is actually minimized. This is useful for scripts that depend on actions being completed before moving on.
windowraise [window_id=%1] Raise the window to the top of the stack. This may not work on all window managers. If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
windowreparent [source_window] destination_window Reparent a window. This moves the source_window to be a child window of destination_window. If no source is given, %1 is the default. "WINDOW STACK" window references (like %1) are valid for both source_window and destination_window See "WINDOW STACK" and "COMMAND CHAINING" for more details.
windowclose [window] Close a window. This action will destroy the window, but will not try to kill the client controlling it. If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
windowquit [window] Close a window gracefully. This action sends a request, allowing the application to apply close confirmation mechanics. If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
windowkill [window] Kill a window. This action will destroy the window and kill the client controlling it. If no window is given, %1 is the default. See WINDOW STACK and "COMMAND CHAINING" for more details.
windowunmap [options] [window_id=%1] Unmap a window, making it no longer appear on your screen. If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
--sync After requesting the window unmap, wait until the window is actually unmapped (hidden). This is useful for scripts that depend on actions being completed before moving on.
set_window [options] [windowid=%1] Set properties about a window. If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
--name newname Set window WM_NAME (the window title, usually)
--icon-name newiconname Set window WM_ICON_NAME (the window title when minimized, usually)
--role newrole Set window WM_WINDOW_ROLE
--classname newclassname Set window class name (not to be confused with window class)
--class newclass Set window class (not to be confused with window class name)
--urgency value Set window urgency hint. If the value is 1, the window will be marked urgent, and the window manager will somehow highlight it for the user's attention.  If the value is 0, the window will be marked non-urgent.
--overrideredirect value Set window's override_redirect value. This value is a hint to the window manager for whether or not it should be managed. If the redirect value is 0, then the window manager will draw borders and treat this window normally. If the value is 1, the window manager will ignore this window.
If you change this value, your window manager may not notice the change until the window is mapped again, so you may want to issue 'windowunmap' and 'windowmap' to make the window manager take note.
These commands follow the EWMH standard. See the section "EXTENDED WINDOW MANAGER HINTS" for more information.
windowactivate [options] [window] Activate the window. This command is different from windowfocus: if the window is on another desktop, we will switch to that desktop. It also uses a different method for bringing the window up. I recommend trying this command before using windowfocus, as it will work on more window managers.
If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
--sync After sending the window activation, wait until the window is actually activated. This is useful for scripts that depend on actions being completed before moving on.
getactivewindow Output the current active window. This command is often more reliable than getwindowfocus. The result is saved to the window stack. See "WINDOW STACK" for more details.
windowstate [--add PROPERTY] [--remove PROPERTY] [--toggle PROPERTY] [window] Change a property on a window.
Some properties may have no effect some windows or in some window managers.
Properties can be any of:
MODAL - makes the window into a modal STICKY - makes the window appear on all workspaces MAXIMIZED_VERT - sizes the window maximized vertically MAXIMIZED_HORZ - sizes the window maximized horizontally ABOVE - Show window above all others (always on top) BELOW - Show window below all others SKIP_TASKBAR - hides the window from the taskbar SKIP_PAGER - hides the window from the window pager FULLSCREEN - makes window fullscreen HIDDEN - unmaps the window SHADED - rolls the window up DEMANDS_ATTENTION - marks window urgent or needing attention
This feature requires a window manager which supports EWMH. Most window managers probably support this :)
getwindowclassname [window] Prints the class name for the window.
set_num_desktops number Changes the number of desktops or workspaces.
get_num_desktops Output the current number of desktops.
get_desktop_viewport [--shell] Report the current viewport's position. If --shell is given, the output is friendly to shell eval.
Viewports are sometimes used instead of 'virtual desktops' on some window managers. A viewport is simply a view on a very large desktop area.
set_desktop_viewport x y Move the viewport to the given position. Not all requests will be obeyed - some windowmangers only obey requests that align to workspace boundaries, such as the screen size.
For example, if your screen is 1280x800, you can move to the 2nd workspace by doing: xdotool set_desktop_viewport 1280 0
set_desktop [options] desktop_number Change the current view to the specified desktop.
--relative Use relative movements instead of absolute. This lets you move relative to the current desktop.
get_desktop Output the current desktop in view.
set_desktop_for_window [window] desktop_number Move a window to a different desktop. If no window is given, %1 is the default. See "WINDOW STACK" and "COMMAND CHAINING" for more details.
get_desktop_for_window [window] Output the desktop currently containing the given window. Move a window to a different desktop. If no window is given, %1 is the default. See WINDOW STACK and "COMMAND CHAINING" for more details.
exec [options] command [...] Execute a program. This is often useful when combined with behave_screen_edge to do things like locking your screen.
--sync Block until the child process exits. The child process exit status is then passed to the parent process (xdotool) which copies it.
Examples: # Lock the screen when the mouse sits in the top-right corner xdotool behave_screen_edge --delay 1000 top-right \ exec gnome-screensaver-command --lock # Substitute 'xscreensaver-command -lock' if you use that program.
# The following will fail to move the mouse because we use '--sync' and # /bin/false exits nonzero: xdotool exec --sync /bin/false mousemove 0 0
# This succeeds, though, since we do not use --sync on the exec command. xdotool exec /bin/false mousemove 0 0
sleep seconds Sleep for a specified period. Fractions of seconds (like 1.3, or 0.4) are valid, here.
xdotool can read a list of commands via stdin or a file if you want. A script will fail when any command fails.
Truthfully, 'script' mode isn't fully fleshed out and may fall below your expectations. If you have suggestions, please email the list or file a bug (See CONTACT).
Scripts can use positional arguments (Represented by $1, $2, ...) and environment variables (like $HOME or $WINDOWID). Quoting arguments should work as expected.
Scripts are processed for parameter and environment variable expansion and then run as if you had invoked xdotool with the entire script on one line (using COMMAND CHAINING).
•   Read commands from a file:
xdotool filename
•   Read commands from stdin:
xdotool -
•   Read commands from a redirected file
xdotool - < myfile
You can also write scripts that only execute xdotool. Example:
#!/usr/local/bin/xdotool search --onlyvisible --classname $1
windowsize %@ $2 $3 windowraise %@
windowmove %1 0 0 windowmove %2 $2 0 windowmove %3 0 $3 windowmove %4 $2 $3
This script will take all windows matched by the classname query given by arg1 ($1) and sizes/moves them into a 2x2 grid with windows sized by the 2nd and 3rd parameters.
Here's an example usage:
% ./myscript xterm 600 400
Running it like this will take 4 visible xterms, raise them, and move them into a 2x2 tile grid with each window 600x400 pixels in size.
Any command taking the --clearmodifiers flag will attempt to clear any active input modifiers during the command and restore them afterwards.
For example, if you were to run this command: xdotool key a
The result would be 'a' or 'A' depending on whether or not you were holding the shift key on your keyboard. Often it is undesirable to have any modifiers active, so you can tell xdotool to clear any active modifiers.
The order of operations if you hold shift while running 'xdotool key --clearmodifiers a' is this:
1. Query for all active modifiers (finds shift, in this case) 2. Try to clear shift by sending 'key up' for the shift key 3. Runs normal 'xdotool key a' 4. Restore shift key by sending 'key down' for shift
The --clearmodifiers flag can currently clear of the following:
•   any key in your active keymap that has a modifier associated with it. (See xmodmap(1)'s 'xmodmap -pm' output)
•   mouse buttons (1, 2, 3, 4, and 5)
•   caps lock
If you are trying to send key input to a specific window, and it does not appear to be working, then it's likely your application is ignoring the events xdotool is generating. This is fairly common.
Sending keystrokes to a specific window uses a different API than simply typing to the active window. If you specify 'xdotool type --window 12345 hello' xdotool will generate key events and send them directly to window 12345.  However, X11 servers will set a special flag on all events generated in this way (see XEvent.xany.send_event in X11's manual). Many programs observe this flag and reject these events.
It is important to note that for key and mouse events, we only use XSendEvent when a specific window is targeted. Otherwise, we use XTEST.
Some programs can be configured to accept events even if they are generated by xdotool. Seek the documentation of your application for help.
Specific application notes (from the author's testing): * Firefox 3 seems to ignore all input when it does not have focus.  * xterm can be configured while running with ctrl+leftclick, 'Allow SendEvents' * gnome- terminal appears to accept generated input by default.
Certain commands (search, getactivewindow, getwindowfocus) will find windows for you. These results generally printed to stdout, but they are also saved to memory for future use during the lifetime of the xdotool process. See "COMMAND CHAINING" for more information.
The only modifications support for the window stack are to replace it. That is, two of two sequential searches, only the last one's results will be the window stack.
xdotool supports running multiple commands on a single invocation. Generally, you'll start with a search command (see "WINDOW STACK") and then perform a set of actions on those results.
To query the window stack, you can use special notation "%N" where N is a number or the '@' symbol. If %N is given, the Nth window will be selected from the window stack. Generally you will only want the first window or all windows.  Note that the order of windows in the window stack corresponds to the window stacking order, i.e. the bottom-most window will be reported first (see XQueryTree(3)). Thus the order of the windows in the window stack may not be consistent across invocations.
The notation described above is used as the "window" argument for any given command.
For example, to resize all xterms to 80x24:
xdotool search --class xterm -- windowsize --usehints %@ 80 24
Resize move the current window:
xdotool getactivewindow windowmove 0 0
In all cases, the default window argument, if omitted, will default to "%1". It is obviously an error if you omit the window argument and the window stack is empty. If you try to use the window stack and it is empty, it is also an error.
To activate the first firefox window found:
xdotool search --class firefox windowactivate
These would error:
xdotool windowactivate xdotool windowactivate %1 xdotool windowactivate %@
When xdotool exits, the current window stack is lost.
Additionally, commands that modify the "WINDOW STACK" will not print the results if they are not the last command. For example:
# Output the active window: % xdotool getactivewindow 20971533
# Output the pid of the active window, but not the active window id: % xdotool getactivewindow getwindowpid 4686
The following pieces of the EWMH standard are supported:
_NET_SUPPORTED Asks the window manager what is supported
_NET_CURRENT_DESKTOP Query and set the current desktop. Support for this enables these commands: "set_desktop", "get_desktop".
_NET_WM_DESKTOP Query and set what desktop a window is living in. Support for this enables these commands: "set_desktop_for_window", "get_desktop_for_window".
_NET_ACTIVE_WINDOW Allows you to query and set the active window by asking the window manager to bring it forward. Support for this enables these commands: "windowactivate", "getactivewindow".
_NET_WM_PID This feature is application dependent, not window-manager dependent. Query the PID owning a given window. Support for this enables these commands: "getwindowpid".
xdotool (and libxdo) will try to function under all circumstances. However, there may be some cases where functionality is not provided by your X server or by your window manager. In these cases, xdotool will try to detect and tell you if an action requires a feature not currently supported by your system.
For window-manager specific features, see "EXTENDED WINDOW MANAGER HINTS".
XTEST If your X server does not support XTEST, then some typing and mouse movement features may not work. Specifically, typing and mouse actions that act on the "current window" (window 0 in libxdo) are unlikely to work.
In most cases, XTEST is a feature you can enable on your X server if it is not enabled by default.
You can see the list of supported X extensions by typing 'xdpyinfo' and looking the text 'number of extensions: ...'
Typing unusual symbols under non-us keybindings is known to occasionally send the wrong character.
xprop(1), xwininfo(1),
Project site: <http://www.semicomplete.com/projects/xdotool>
Source code and Issues: <https://github.com/jordansissel/xdotool>
EWMH specification: <http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html>
Please send questions to xdotool-users@googlegroups.com. File bugs and feature requests at the following URL:
<https://github.com/jordansissel/xdotool/issues>
Alternately, if you prefer email, feel free to file bugs by emailing the list.  What works for you :)
xdotool was written by Jordan Sissel.
This manual page was written originally by Daniel Kahn Gillmor <dkg@fifthhorseman.net> for the Debian project (but may be used by others). It is maintained by Jordan Sissel.
Patches, ideas, and other contributions by many, nice folks. See the CHANGELIST file for who provided what.
IMGP(1)                           User Commands                          IMGP(1)
imgp - Resize, rotate JPEG and PNG images.
imgp [OPTIONS] [PATH [PATH ...]]
imgp is a multiprocessing command line image resizer and rotator for JPEG and PNG images.
* resize by percentage or resolution * rotate clockwise by specified angle * adaptive resize considering orientation * brute force to a resolution * optimize images to save more space * limit processing by minimum image size * convert PNG to JPEG * erase exif metadata * specify output JPEG image quality * force smaller to larger resize * process directories recursively * overwrite source image option
Adaptive mode
- If the specified and image orientations are same [(H >= V and h > v) or (H < V and h < v)], the image is resized with the longer specified side as reference. - In case of cross orientation [(H >= V and h <= v) or (H < V and h >= v)], the image is resized with the shorter specified side as reference. Same as non-adaptive.
For example, if an image has a resolution of 2048x1365 and is being resized to 1366x768: - In regular mode (default), output image resolution will be 1152x768 - In adaptive mode, output image resolution will be 1366x910
Operational notes
- Multiple files and directories can be specified as source. If PATH is omitted, the current directory is processed. - Output image names are appended with _IMGP if '--overwrite' option is not used. By default _IMGP files are not processed. Doing so may lead to potential race conditions when '--overwrite' option is used. - PNG files with lower target hres/vres are not converted (even if '--convert' is used). Run 'imgp --convert (*.png)' separately to convert those. - Resize and rotate are lossy operations. For additional reductions in size try '--optimize' and '--eraseexif' options. - Option '--optimize' is slower, the encoder makes an extra pass over the image in order to select optimal encoder settings. - Progressive JPEG images are saved as progressive.
-h, --help Show help text and exit.
-x, --res=res Output resolution in HRESxVRES or percentage.
-o, --rotate=deg Rotate clockwise by a specified angle (in degrees). Negative inputs rotate anti-clockwise. Rotation by 0 degree is not allowed.
-a, --adapt Adapt to specified resolution considering the orientation of the image. Disabled by default.
-c, --convert Convert PNG images to JPEG to save on space. The output image is saved with '.jpg' extension.
-d, --dot Include hidden files (Linux-specific). By default hidden files are skipped on Linux.
-e, --eraseexif Erase EXIF metadata of JPEG images. Preserved by default.
-f, --force Force to the exact specified resolution. Disabled by default.
-i, --includeimgp Process _IMGP files. Risky due to potential race conditions.
-k, --keep Do not process if image hres or vres matches specified hres or vres, or --res is 100. However, PNG images are converted to JPEG if --convert option is specified and JPEG images are made progressive is --progressive option is specified.
-n, --enlarge Enlarge smaller images. By default smaller images are not scaled if specified resolution is greater.
--nn   Use nearest neighbour interpolation for PNG images instead of default antialias.
-p, --optimize Optimize output images using PIL library optimization algorithm. Disabled by default.
--pr, --progressive Save all output JPEG images as progressive, even if the source is not.
-q, --quality=N Save the image with a specified quality factor N (scale 1-95, default 75). JPEG only.
-m, --mute Do not show any operational output.
-r, --recurse Recursively process sub-directories. By default only the specified directory is processed. Symbolic links are ignored to avoid recursive loops.
-s, --size=byte Minimum size in bytes required to process an image. Acts as a guard against processing low-resolution images. Default 1024 bytes.
-w, --overwrite Overwrite the source images. By default an output image is saved with _IMGP appended to the source image name. NOTE: If overwrite and convert options are used together, source PNG images are deleted.
-z, --debug Enable debugging.
1.  Convert some images and directories:
$ imgp -x 1366x768 ~/ ~/Pictures/image3.png ~/Downloads/ /home/testuser/image1.png 3840x2160 -> 1365x768 11104999 bytes -> 1486426 bytes
/home/testuser/image2.jpg 2048x1365 -> 1152x768 224642 bytes -> 31421 bytes
/home/testuser/Pictures/image3.png 1920x1080 -> 1365x768 2811155 bytes -> 1657474 bytes
/home/testuser/Downloads/image4 2048x1365 -> 1152x768 224642 bytes -> 31421 bytes
2.  Scale an image by 75% and overwrite the source image:
$ imgp -x 75 -w ~/image.jpg /home/testuser/image.jpg 1366x767 -> 1025x575 120968 bytes -> 45040 bytes
3.  Rotate an image clockwise by 90 degrees:
$ imgp -o 90 ~/image.jpg 120968 bytes -> 72038 bytes
4.  Adapt the images in the current directory to 1366x1000 resolution. Visit all directories recursively, overwrite source images, ignore images with matching hres or vres but convert PNG images to JPEG.
$ imgp -x 1366x1000 -wrack
5.  Set hres=800 and adapt vres maintaining the ratio.
$ imgp -x 800x0 Source omitted. Processing current directory...
./image1.jpg 1366x911 -> 800x534 69022 bytes -> 35123 bytes
./image2.jpg 1050x1400 -> 800x1067 458092 bytes -> 78089 bytes
6.  Process images greater than 50KB (50*1024 bytes) only:
$ imgp -wrackx 1366x1000 -s 51200
https://github.com/jarun/imgp
https://github.com/jarun/imgp/issues
Copyright Â© 2016-2018 Arun Prakash Jana <engineerarun@gmail.com>
exec(3tcl)                    Tcl Built-In Commands                   exec(3tcl)
exec - Invoke subprocesses
exec ?switches? arg ?arg ...? ?&?
________________________________________________________________________________
This command treats its arguments as the specification of one or more subprocesses to execute.  The arguments take the form of a standard shell pipeline where each arg becomes one word of a command, and each distinct command becomes a subprocess.
If the initial arguments to exec start with - then they are treated as command-line switches and are not part of the pipeline specification. The following switches are currently supported:
-ignorestderr Stops the exec command from treating the output of messages to the pipeline's standard error channel as an error case.
-keepnewline Retains a trailing newline in the pipeline's output. Normally a trailing newline will be deleted.
--           Marks the end of switches.  The argument following this one will be treated as the first arg even if it starts with a -.
If an arg (or pair of args) has one of the forms described below then it is used by exec to control the flow of input and output among the subprocess(es).  Such arguments will not be passed to the subprocess(es). In forms such as “< fileName”, fileName may either be in a separate argument from “<” or in the same argument with no intervening space (i.e. “<fileName”).
|              Separates distinct commands in the pipeline.  The standard output of the preceding command will be piped into the standard input of the next command.
|&             Separates distinct commands in the pipeline.  Both standard output and standard error of the preceding command will be piped into the standard input of the next command.  This form of redirection overrides forms such as 2> and >&.
< fileName     The file named by fileName is opened and used as the standard input for the first command in the pipeline.
<@ fileId      FileId must be the identifier for an open file, such as the return value from a previous call to open.  It is used as the standard input for the first command in the pipeline.  FileId must have been opened for reading.
<< value       Value is passed to the first command as its standard input.
> fileName     Standard output from the last command is redirected to the file named fileName, overwriting its previous contents.
2> fileName    Standard error from all commands in the pipeline is redirected to the file named fileName, overwriting its previous contents.
>& fileName    Both standard output from the last command and standard error from all commands are redirected to the file named fileName, overwriting its previous contents.
>> fileName    Standard output from the last command is redirected to the file named fileName, appending to it rather than overwriting it.
2>> fileName   Standard error from all commands in the pipeline is redirected to the file named fileName, appending to it rather than overwriting it.
>>& fileName   Both standard output from the last command and standard error from all commands are redirected to the file named fileName, appending to it rather than overwriting it.
>@ fileId      FileId must be the identifier for an open file, such as the return value from a previous call to open.  Standard output from the last command is redirected to fileId's file, which must have been opened for writing.
2>@ fileId     FileId must be the identifier for an open file, such as the return value from a previous call to open.  Standard error from all commands in the pipeline is redirected to fileId's file.  The file must have been opened for writing.
2>@1           Standard error from all commands in the pipeline is redirected to the command result.  This operator is only valid at the end of the command pipeline.
>&@ fileId     FileId must be the identifier for an open file, such as the return value from a previous call to open.  Both standard output from the last command and standard error from all commands are redirected to fileId's file.  The file must have been opened for writing.
If standard output has not been redirected then the exec command returns the standard output from the last command in the pipeline, unless “2>@1” was specified, in which case standard error is included as well.  If any of the commands in the pipeline exit abnormally or are killed or suspended, then exec will return an error and the error message will include the pipeline's output followed by error messages describing the abnormal terminations; the -errorcode return option will contain additional information about the last abnormal termination encountered. If any of the commands writes to its standard error file and that standard error is not redirected and -ignorestderr is not specified, then exec will return an error;  the error message will include the pipeline's standard output, followed by messages about abnormal terminations (if any), followed by the standard error output.
If the last character of the result or error message is a newline then that character is normally deleted from the result or error message. This is consistent with other Tcl return values, which do not normally end with newlines.  However, if -keepnewline is specified then the trailing newline is retained.
If standard input is not redirected with “<”, “<<” or “<@” then the standard input for the first command in the pipeline is taken from the application's current standard input.
If the last arg is “&” then the pipeline will be executed in background. In this case the exec command will return a list whose elements are the process identifiers for all of the subprocesses in the pipeline.  The standard output from the last command in the pipeline will go to the application's standard output if it has not been redirected, and error output from all of the commands in the pipeline will go to the application's standard error file unless redirected.
The first word in each command is taken as the command name; tilde- substitution is performed on it, and if the result contains no slashes then the directories in the PATH environment variable are searched for an executable by the given name.  If the name contains a slash then it must refer to an executable reachable from the current directory.  No “glob” expansion or other shell-like substitutions are performed on the arguments to commands.
Windows (all versions) Reading from or writing to a socket, using the “@ fileId” notation, does not work.  When reading from a socket, a 16-bit DOS application will hang and a 32-bit application will return immediately with end-of-file.  When either type of application writes to a socket, the information is instead sent to the console, if one is present, or is discarded.
Note that the current escape resp. quoting of arguments for windows works only with executables using CommandLineToArgv, CRT- library or similar, as well as with the windows batch files (excepting the newline, see below).  Although it is the common escape algorithm, but, in fact, the way how the executable parses the command-line (resp. splits it into single arguments) is decisive.
Unfortunately, there is currently no way to supply newline character within an argument to the batch files (.cmd or .bat) or to the command processor (cmd.exe /c), because this causes truncation of command-line (also the argument chain) on the first newline character.  But it works properly with an executable (using CommandLineToArgv, etc).
The Tk console text widget does not provide real standard IO capabilities.  Under Tk, when redirecting from standard input, all applications will see an immediate end-of-file; information redirected to standard output or standard error will be discarded.
Either forward or backward slashes are accepted as path separators for arguments to Tcl commands.  When executing an application, the path name specified for the application may also contain forward or backward slashes as path separators.  Bear in mind, however, that most Windows applications accept arguments with forward slashes only as option delimiters and backslashes only in paths. Any arguments to an application that specify a path name with forward slashes will not automatically be converted to use the backslash character.  If an argument contains forward slashes as the path separator, it may or may not be recognized as a path name, depending on the program.
Additionally, when calling a 16-bit DOS or Windows 3.X application, all path names must use the short, cryptic, path format (e.g., using “applba~1.def” instead of “applbakery.default”), which can be obtained with the “file attributes fileName -shortname” command.
Two or more forward or backward slashes in a row in a path refer to a network path.  For example, a simple concatenation of the root directory c:/ with a subdirectory /windows/system will yield c://windows/system (two slashes together), which refers to the mount point called system on the machine called windows (and the c:/ is ignored), and is not equivalent to c:/windows/system, which describes a directory on the current computer.  The file join command should be used to concatenate path components.
Note that there are two general types of Win32 console applications:
[1]    CLI — CommandLine Interface, simple stdio exchange. netstat.exe for example.
[2]    TUI — Textmode User Interface, any application that accesses the console API for doing such things as cursor movement, setting text color, detecting key presses and mouse movement, etc.  An example would be telnet.exe from Windows 2000.  These types of applications are not common in a windows environment, but do exist.