Bug: ydotool sub-command help menus erroneously require the ydotoold daemon to be running to display help information

[ElectricRCAircraftGuy]

Version: ydotoold --version shows v1.0.4-0-g57ba7d0. There's my hash. I built it from the latest commit.

OS: Ubuntu 22.04.2 (tested in both X11 and Wayland)

When I run ydotool key -h, ydotool click -h, etc., I expect to see the help menus for those sub-commands. Instead, I see:

$ ydotool key -h
failed to connect socket `/run/user/1000/.ydotool_socket': No such file or directory
Please check if ydotoold is running.

This is because the program is mistakenly looking for the daemon instead of just displaying the help menu. Please update the code to not check for a running daemon when just trying to display the help menu.

A workaround is this:

# 1. start the daemon
sudo -b ydotoold --socket-path="$HOME/.ydotool_socket" --socket-own="$(id -u):$(id -g)"

# 2. Now the help menus work, with the proper environment variable setting
YDOTOOL_SOCKET="$HOME/.ydotool_socket" ydotool key -h

Example run and output of the help menu:

$ YDOTOOL_SOCKET="$HOME/.ydotool_socket" ydotool key -h
Usage: key [OPTION]... [KEYCODES]...
Emit key events.

Options:
  -d, --key-delay=N          Delay N milliseconds between key events
  -h, --help                 Display this help and exit

Since there's no way to know how many keyboard layouts are there in the world,
we're using raw keycodes now.

Syntax: <keycode>:<pressed>
e.g. 28:1 28:0 means pressing on the Enter button on a standard US keyboard.
     (where :1 for pressed means the key is down and then :0 means the key is released)     42:1 38:1 38:0 24:1 24:0 38:1 38:0 42:0 - "LOL"

Non-interpretable values, such as 0, aaa, l0l, will only cause a delay.

See `/usr/include/linux/input-event-codes.h' for available key codes (KEY_*).