I'm on Ubuntu 19.04 and I installed ydotool via the .deb file available in the Releases tab. I have the package libboost-program-options-dev installed, but I still get this error message:

ydotool: error while loading shared libraries: libboost_program_options.so.1.65.1: cannot open shared object file: No such file or directory

I tried installing also libboost-program-options-dev:i386, with no success.

Hello, thanks for creating this tool! I'm trying to use ydotool to emulate numpad key pressed, but so far I had no success - I don't know how to make ydotool press the numpad key. I tried things like:

ydotool key MINUS
ydotool key KPMINUS

But neither of them work. Any suggestions?

I tried to record some events:

sudo ydotool recorder --record foo
sudo ydotool recorder --display foo

This outputs some logs similar to this:

Offset: 0x2a0
Delay: 0.063964392 second
Event: 4, 4, 458758
-
Offset: 0x2b8
Delay: 0.000004128 second
Event: 1, 46, 1
-
Offset: 0x2d0
Delay: 0.000001284 second
Event: 0, 0, 0

What this Offset value and these Event values and how am I supposed to use them to type ydotools commands?

I tried sudo ydotool key 0x2d0 but triggers the 0 keyboard key, because 0x2d0 starts with a 0.

ydotool can be quite annoying to install especially due to the fact it relies on 2 libraries which aren't commonly used.

It would be nice if the release section provided more up to date binaries and binaries that are statically linked with libuInputPlus.so.0 and libevdevPlus.so.0

After recent changes to cmake configuration,, make install installs libydotool.so and libydotool.a into /usr/local/bin instead of /usr/local/lib.

Since ldconfig does not normally look in /usr/local/bin for shared objects, libydotool.so cannot be found, so ydotoold does not start:

ydotoold: error while loading shared libraries: libydotool.so: cannot open shared object file: No such file or directory

Until cmake is reconfigured, you could work around this after install by manually moving these two files to a directory that ldconfig searches, and trigger ldconfig to rescan:

sudo mv /usr/local/bin/libydotool.{so,a} /usr/local/lib/
sudo ldconfig

Please version the libydotool.so package as the fedora packaging guidelines require all shared libraries to be versioned - I am not allowed to package ydotool for fedora with an unversioned shared library. I can versioned it in a patch downstream here in fedora-land but there is a danger that I would choose version numbers that conflict or misalign with a future version number chosen by upstream (yourself).

Much better if you can do the versioning.

Thanks - and thanks again for a great package - I would not be using sway if it were not for ydotool (I would stick to i3wm/xdotool/xvkbd).

Key naming is not compatible with xdotool (e.g. ydotool key space and ydotool key return don't work but ydotool key " " and ydotool key enter do). It would be nice if there was a link in the readme to somewhere that listed valid keys.

When using ydotoold in scripts one has to start the daemon using ydotoold&. When using ydotool type too quickly this results in a few characters being lost. It would be nice if the ydotool daemon actually forks once it's started to make handling easier.

Hello,

The "type" command does not work with "special characters", example:

$> ydotool type "Hello world 🤣é²@42"
ydotool: notice: Using ydotoold backend
Hello world %

$> Hello world

Hi,

Is there a way to run ydotool/ydotoold without sudo/root ?

thanks

ydotool works great for the implemented features. It seems I need xdotool to get the windows id? and xwininfo to get the window coords

xdotool search --onlyvisible --class google-chrome
(this will return a window id)

use
xwininfo -id
(this will return the cords of the window)

and I can use xdotool to set a windows on top

Am I suppose to use these 3 programs together to do things?
Or am I doing things wrong?

I understand with the changes in Wayland it may not be possible, but at the same time it looks like this may just be getting offloaded to the DE and could be obtained via dbus signals with the DE? I am also wondering if the DE's aren't still getting this info from Wayland too though. Either way it'd be a highly useful function to implement.

Hello!

I am getting the following build error:

/home/aviau/git/ydotool/Tools/Key/Key.cpp: In function ‘std::vector<int> KeyStroke2Code(const string&)’:
/home/aviau/git/ydotool/Tools/Key/Key.cpp:72:16: error: ‘Table_ModifierKeys’ was not declared in this scope
   72 |   auto t_kms = Table_ModifierKeys.find(it);
      |                ^~~~~~~~~~~~~~~~~~
make[2]: *** [CMakeFiles/ydotool_library.dir/build.make:167: CMakeFiles/ydotool_library.dir/Tools/Key/Key.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:191: CMakeFiles/ydotool_library.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

It looks like there is something missing in that file? Or is the tool incomplete?

Cheers,

I'm using rofi-pass on arch linux with the ydotool patch from aur.

pacman -Qi ydotool-git reports Version: v0.1.8.r29.g7764122-3

When I open rofi-pass, it loses focus after a short time (a second or so). Also when holding a key down in a terminal the key doesn't repeat or stops after a short time. If I stop ydotoold, the key repeats normally.

can I fix this with some config change or is this a problem with ydotoold itself?

I have a keyboard mapping issue, it's like ydotools types on a keyboard with a wrong keyboard mapping:

$ sudo ydotool type 'azerty'
ydotool: notice: ydotoold backend unavailable (may have latency+delay issues)
qwerty%
$ qwerty

Any plan to implement these features from the xdotool? These would be immensely helpful for actions such as app cycling.

Currently if I run commands that should just print help messages, ydotool will close with an error.
Examples:
ydotool click
ydotool click --help

No special permissions should be required to print help text.

i've tested wayland, libinput-gestures with ydotool/mousemove_relative to simulate three finger drag. still too much latency even with the daemon.

i intended to replace x11, libinput-gestures, xdotool - with the above; but no luck for now

Hello!

It would be great if you provided a manpage so that it can be included in distributions that package ydotool.

( I am a Debian Developper and I am preparing a Debian package)

Having a systemd service file would allow packagers to install it to the correct place on the users system so they could just do, for example: systemctl --user enable --now ydotoold to have it run on startup.

You can have a look at my service file here. The install section would need to be adjusted to use a more generic target to not be Sway specific.

I just wanted to open up this issue before bothering with a PR, to see if you are interested. Let me know what you think.

Hi,
please see this comment reported on the Arch Linux AUR package:

https://aur.archlinux.org/packages/ydotool-git/#comment-710452

User reports the following linking issue, which I was able to reproduce in a clean Docker container:

[100%] Linking CXX executable ydotool_static
/usr/bin/ld: cannot find -luInputPlus
/usr/bin/ld: cannot find -levdevPlus
/usr/bin/ld: libydotool.a(Tool.cpp.o): in function `ydotool::Tool::ToolManager::TryDlOpen(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
Tool.cpp:(.text+0x20e): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: cannot find -luInputPlus
/usr/bin/ld: cannot find -levdevPlus
collect2: error: ld returned 1 exit status

I believe it's an issue with the build scripts, but I couldn't find anything weird.

See the following asciinema for an example of a container build: https://asciinema.org/a/yJKDNWfhzs83xGHGMDkX0Pp2L

It's pretty much this:

pacman -Syu base-devel git sudo
useradd -m -G wheel user
visudo
## (enable passwordless sudo for wheel users)
su - user
git clone https://aur.archlinux.org/yay-bin.git
cd yay-bin
makepkg
sudo pacman -U yay-bin*.pkg.*
yay -S ydotool-git

Good project !!
I tried type unicode characters as below, but they didn't appeared. Ascii char's are well.
Is there any idea?

---- unicode ----
% ydotool type テスト
ydotool: Executing `type' at 0x7fff66cc3928
argc = 2
argv[1] = テスト

---- ascii ----
% ydotool type test
ydotool: Executing `type' at 0x7ffd1a5d9f78
argc = 2
argv[1] = test
test

The output of ydotool key --help says:

Since we are emulating keyboard input, combination like Shift+# is invalid.
Because typing a `#' involves pressing Shift and 3.

However, that's not true for some keyboard layouts. For example, on the german layout the #-key is an own key next to the enter key. So on german keyboards the combination Shift+# would actually work.

subj

I successfully compiled and installed the three listed dependencies. Then I successfully built and installed ydotool. But when I run it I get this error:

$ ydotool
ydotool: error while loading shared libraries: libuInputPlus.so.0: cannot open shared object file: No such file or directory

I'm on ArchLinux (1.4? ArchLabs 2019.1.20)

The fedora auditing tools picked up the fact that the libydotool.so shared library calls exit (in several places). A quick google on the topic led me to this explanation:

simbody/simbody#659:

Calling exit in a shared libary is generally considered bad practice, as the caller has no way to catch the call, and you will be exiting the main application (the caller).

I would suggest to replace all exit calls by throwing an exception. If the exception is not caught, the behavior will be the same as it is now, but a caller has the option to catch the exception and react appropriately.

Hi, if I type in ydotool type "This is a test" I get this instead: Ydco co a y.oyv which signifies that ydotool is typing in QWERTY, not Dvorak.

For reference, I'm using sway as my WM and the following lines of config:

input * xkb_layout "us,us"
input * xkb_variant ",dvorak"
input * xkb_options "grp:shifts_toggle, caps:swapescape"

(aur: ydotool-git v0.1.5.r4.ged1e20f-1)
I just provide the terminal output

% ydotool key a                                                                  
ydotool: Executing `key' at 0x7fff41c8eef8
argc = 2
argv[1] = a
a⏎
        
% ydotool key --delay 5 a                                                 
ydotool: Executing `key' at 0x7ffff9298f78
argc = 4
argv[1] = --delay
argv[2] = 5
argv[3] = a
Delay was set to 5 milliseconds.

% ydotool key --delay 100 a                                               
ydotool: Executing `key' at 0x7fff83835f08
argc = 4
argv[1] = --delay
argv[2] = 100
argv[3] = a
Delay was set to 64 milliseconds.
a⏎
    
% ydotool key --delay 15 a                                                
ydotool: Executing `key' at 0x7ffc64b01098
argc = 4
argv[1] = --delay
argv[2] = 15
argv[3] = a
Delay was set to f milliseconds.

% ydotool key --delay 10 a                                             
ydotool: Executing `key' at 0x7fffb7bc8818
argc = 4
argv[1] = --delay
argv[2] = 10
argv[3] = a
Delay was set to a milliseconds.

% ydotool key --delay 150 a                                               
ydotool: Executing `key' at 0x7fff6f31f728
argc = 4
argv[1] = --delay
argv[2] = 150
argv[3] = a
Delay was set to 96 milliseconds.
a⏎                                                                                       

Also as seen, in some cases keycodes aren't event sent

Is there a forum or mailing list?

Hi, I just found your project and I like it a lot :)

I'm having an issue though: if I run ydotool key down, I would expect it to press the "arrow down" key. However it types d instead.

Also it seems to deduplicate keys. If I run ydotool key h e l l o it types helo, even if I add more Ls around it only keeps one (I know there's type for that but I'd like to report this issue as well :) ).

EDIT:
I kept using it and I've noticed a bunch of more keys aren't recognized. I'll add them to the following list when I find them:

• Arrow keys
• Super
• XF86*

(I made an ArchLinux AUR package for ydotool and its dependencies: https://aur.archlinux.org/packages/ydotool-git/)

Hi,
I am Arch Linux Trusted User and I would like to push your software to our official repositories.
If you are interested it would be glad if you could schedule stable releases for your software.
This would make packaging a lot easier. Thanks

Hi there,

I'm trying to compile this project on openSUSE tumbleweed so that I can make it available to download using the opensuse pacakge manager.

I've successfully compiled libuinputplus and libevdevplus but I cannot figure out what boost::program_options actually is. Would you mind elaborating on this so that I can try searching for it in the official opensuse repos?

Would you mind also explaining the difference between libuinputplus/libevdevplus and the standard libraries libuinput and libevdev? (If I can just use the latter it would make the build process a lot simpler)

bug

Would it be possible to create a cmake flag to link ydotool as static?

I can build ydotool_client_static but then make install won't install it.

Also, is there a way to link ydotoold staticly?

ydotool: Unknown tool: mousemove_relative Run 'ydotool help' if you want a tools list

compiling from 9c3a4e7 is OK
compiling (per the README) from 9117331 (master) is broken:

[ 73%] Linking CXX shared library libydotool.so
[ 76%] Linking CXX static library libydotool.a
[ 76%] Built target ydotool_library_static
Scanning dependencies of target ydotool_static
Scanning dependencies of target ydotoold_static
[ 79%] Building CXX object CMakeFiles/ydotool_static.dir/Client/ydotool.cpp.o
[ 82%] Building CXX object CMakeFiles/ydotoold_static.dir/Daemon/ydotoold.cpp.o
[ 82%] Built target ydotool_library
Scanning dependencies of target ydotool
Scanning dependencies of target ydotoold
[ 85%] Building CXX object CMakeFiles/ydotool.dir/Client/ydotool.cpp.o
[ 88%] Building CXX object CMakeFiles/ydotoold.dir/Daemon/ydotoold.cpp.o
[ 91%] Linking CXX executable ydotoold_static
/usr/bin/ld: cannot find -ldl
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lboost_program_options
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/ydotoold_static.dir/build.make:85: ydotoold_static] Error 1
make[1]: *** [CMakeFiles/Makefile2:86: CMakeFiles/ydotoold_static.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 94%] Linking CXX executable ydotool_static
/usr/bin/ld: cannot find -lboost_program_options
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -ldl
/usr/bin/ld: cannot find -lboost_program_options
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/ydotool_static.dir/build.make:85: ydotool_static] Error 1
make[1]: *** [CMakeFiles/Makefile2:221: CMakeFiles/ydotool_static.dir/all] Error 2
[ 97%] Linking CXX executable ydotoold
[100%] Linking CXX executable ydotool
[100%] Built target ydotoold
[100%] Built target ydotool
make: *** [Makefile:152: all] Error 2

I'm trying to compile and install ydotool on Ubuntu 19.04 but am getting the following error after following the build instructions and running make -j nproc:

Scanning dependencies of target ydotool_library_static Scanning dependencies of target ydotool_library [ 5%] Building CXX object CMakeFiles/ydotool_library_static.dir/Library/Instance.cpp.o [ 10%] Building CXX object CMakeFiles/ydotool_library_static.dir/Library/Tool.cpp.o [ 15%] Building CXX object CMakeFiles/ydotool_library_static.dir/Library/libydotool.cpp.o [ 20%] Building CXX object CMakeFiles/ydotool_library.dir/Library/libydotool.cpp.o [ 25%] Building CXX object CMakeFiles/ydotool_library.dir/Library/Tool.cpp.o [ 30%] Building CXX object CMakeFiles/ydotool_library.dir/Library/Instance.cpp.o [ 35%] Linking CXX static library libydotool.a [ 35%] Built target ydotool_library_static [ 40%] Linking CXX shared library libydotool.so [ 40%] Built target ydotool_library Scanning dependencies of target type Scanning dependencies of target click Scanning dependencies of target key Scanning dependencies of target ydotoold [ 45%] Building CXX object CMakeFiles/type.dir/Tools/Type/Type.cpp.o [ 50%] Building CXX object CMakeFiles/key.dir/Tools/Key/Key.cpp.o [ 55%] Building CXX object CMakeFiles/ydotoold.dir/Daemon/ydotoold.cpp.o [ 60%] Building CXX object CMakeFiles/click.dir/Tools/Click/Click.cpp.o /home/rwbarat/ydotool/Tools/Key/Key.cpp: In function ‘std::vector<int> KeyStroke2Code(const string&)’: /home/rwbarat/ydotool/Tools/Key/Key.cpp:73:16: error: ‘Table_ModifierKeys’ was not declared in this scope auto t_kms = Table_ModifierKeys.find(it); ^~~~~~~~~~~~~~~~~~ /home/rwbarat/ydotool/Daemon/ydotoold.cpp: In function ‘int client_handler(int)’: /home/rwbarat/ydotool/Daemon/ydotoold.cpp:31:2: error: ‘uInputRawData’ was not declared in this scope uInputRawData buf{0}; ^~~~~~~~~~~~~ /home/rwbarat/ydotool/Daemon/ydotoold.cpp:34:22: error: ‘buf’ was not declared in this scope int rc = recv(fd, &buf, sizeof(buf), MSG_WAITALL); ^~~ make[2]: *** [CMakeFiles/ydotoold.dir/build.make:63: CMakeFiles/ydotoold.dir/Daemon/ydotoold.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:147: CMakeFiles/ydotoold.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... make[2]: *** [CMakeFiles/key.dir/build.make:63: CMakeFiles/key.dir/Tools/Key/Key.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:110: CMakeFiles/key.dir/all] Error 2 [ 65%] Linking CXX shared library libclick.so [ 70%] Linking CXX shared library libtype.so [ 70%] Built target click [ 70%] Built target type make: *** [Makefile:152: all] Error 2

Hello,
I'd like to make a PPA for Ubuntu/Debian based distros of your project. My question is, what this program uses from boost-libs? Because Debian based distros hasn't got a separate boost-libs package so I need to intall the complete libboost-all-dev to be sure that the required function is included, but it's over 500MB.

Thank you in advance,
Daniel

My typical usage for this is repeating a command several times.
To avoid me having to make a while loop whenever I use this command, it would be great if you could add a --repeat argument like xdotool has.

Examples usage:
ydotool type 1 --repeat 10 -> "1111111111"

Since ydotool type $string doesn't support any method to escape characters or otherwise indicate the beginning and end of the actual string to be typed, when I try to type a string beginning with '-', it complains about an unrecognized option.

I'm using rofi-pass, and I can see that some of my passwords are not correctly typed by ydotool, with the french caracters 'é', or 'à' or 'è'…

For example if I enter
ydotool type "Hello, it's working, after é it is not"
it returns:
Hello, it's working, after but nothing after the special caracter.

Is there a way to record input for ydootol, to replay it later?

One example where it can be useful is automated benchmarkng for games. I.e. consider such scenario:

1. Start the game, then record the input while you perform certain actions that you want to benchmark.
2. Start the game again, and replay the input. Capture performance metrics logs.

This can create a way to run a reproducible benchmark for any game, but recording part is quite critical, since you can't really manually construct such input.

I installed ydotools from sources and experienced this issue:

$ pwd # I execute ydotool binary from the build folder, just to be sure
[...]/ydotool/build
$./ydotool type 'Hey guys. This is Austin.'
ydotool: notice: ydotoold backend unavailable (may have latency+delay issues)
terminate called after throwing an instance of 'std::runtime_error'
  what():  failed to open uinput device
zsh: abort (core dumped)  ./ydotool type 'Hey guys. This is Austin.'
ydotool type 'Hey guys. This is Austin.'

Additional information:

$ ./ydotool help
<prints the help menu successfully>
$ ls /usr/lib/libuInputPlus.so /usr/lib/libydotool.so /usr/lib/libevdevPlus.so
/usr/lib/libevdevPlus.so  /usr/lib/libuInputPlus.so  /usr/lib/libydotool.so

I've built some packages for fedora-30/31 in COPR (only tested on f-31). x86_64 only so far.

They were built against head of tree on 20200211.

I've added a systemd service file (see below).

Other RPM builds (eg f-29, OpenSuse, Centos, i386 etc) are only a click away for me so let me know if you need one.

To install:

sudo dnf copr enable wef/ydotool 
sudo dnf copr enable wef/libuInputPlus
sudo dnf copr enable wef/libevdevPlus
sudo dnf install ydotool

Optionally:

sudo systemctl enable ydotoold
sudo systemctl start ydotoold

/usr/lib/systemd/system/ydotoold.service:

[Unit]
Description=Starts ydotoold service
After=network.target

[Service]
Type=simple
Restart=always
ExecStart=/usr/bin/ydotoold
ExecReload=/usr/bin/kill -HUP $MAINPID
KillMode=process
TimeoutSec=180

[Install]
WantedBy=multi-user.target

Hi ! is it possible to get the current mouse position in Wayland ? It would really help me make scripts.

I looked on Google but found no answer to my question.

Thanks in advance !

Many CLI programs have the --version option (among with an eventual shortcut -v).

Among other things, the program version will be a useful information when creating new issues here. It's also a common command to check that the program is successfully installed.

On Arch with latest aur build I've got this issue when trying to use ydotool with the daemon. I also have updated libuinputplus to latest aur build.

Starting the daemon itself works fine:

> sudo ydotoold
ydotoold: listening on socket /tmp/.ydotool_socket
ydotoold: accepted client

But then when trying ydotool in another terminal:

> sudo ydotool type 'test'
ydotool: library search path: /usr/local/lib/ydotool:/usr/lib/ydotool:/usr/lib/x86_64-linux-gnu/ydotool:/usr/lib/i386-linux-gnu/ydotool

ydotool: notice: Using ydotoold backend
ydotool: debug: tool `type' constructed at 0x5620997e4a10
argc = 2
argv[1] = test
Usage: ydotool <cmd> <args>
Available commands:
  mousemove
  type
  key
  click
zsh: segmentation fault  sudo ydotool type 'test'

Trying this in gdb I've got this backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000100140001 in ?? ()
(gdb) bt
#0  0x0000000100140001 in ?? ()
#1  0x89503bf2b6585900 in ?? ()
#2  0x00007fffffffe120 in ?? ()
#3  0x00007ffff7f98984 in uInputPlus::uInput::Emit(unsigned short, unsigned short, int) const () from /usr/lib/libuInputPlus.so.0
#4  0x00007ffff7f989ef in uInputPlus::uInput::SendKey(unsigned short, unsigned int, bool) const () from /usr/lib/libuInputPlus.so.0
#5  0x00007ffff794bb92 in Type::TypeText(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/ydotool/libtype.so
#6  0x00007ffff794cc1e in Type::Exec(int, char const**) () from /usr/lib/ydotool/libtype.so
#7  0x0000555555557451 in main ()

ydotool without the daemon works fine.

archlinux, gnome 3.34, runs on xorg

an example: