0

I'm trying to write a bash script (very new to writing them btw) on a Linux system, and I basically want it to execute a command every say 5 seconds while another command isn't outputting a value.

So what I've got so far is xev | grep -A2 --line-buffered -E 'ButtonRelease' | grep -o 'button 1' which essentially outputs "button 1" when I click the xev window. I want to run a separate command every 5 seconds (xdotool mousemove 1401 1139 click 1) until I click on the xev window at which point the script stops.

Improve this question
3
  • Sorry, I'm not sure I follow ... could you, rather than telling us what you're trying to do, tell us what the goal of this exercise is? What's the final outcome of this? Commented Mar 23 at 8:32
  • I'm trying to make an autoclicker with a button to turn it off, no need for any terminal input. I assume there's numerous ways to do this but want to know if what I'm asking in the question is achievable because I feel it would help me understand how scripts work. Commented Mar 23 at 8:39
  • I believe it is command-line. The command I'm trying to run every 5 seconds is "xdotool mousemove 1401 1139 click 1" Commented Mar 23 at 18:43

2 Answers 2

Reset to default
1

If your command returns immediately, then just take your command and write the output to a variable.

output=$(xev | grep -A2 --line-buffered -E 'ButtonRelease' | grep -o 'button 1')

Then test if the output is empty with

[ -z "$output" ]

You can stick that in a while loop:

output=""

while [ -z "$output" ] ; do
    sleep 5
    output=$(xev | grep -A2 -E 'ButtonRelease' | grep --line-buffered -o 'button 1')
done

If your command is a blocking process, and you want to execute something based on its output, then you'll need to fork, and monitor that output.

# Make a temporary file
output=$(mktemp)

# Run your command
# > "$output" will send the output of that command to a file.
# The & at the end is a "fork".  It means we will continue the script # while that command is running. You also need the --line-buffered 
# option for all grep calls used
xev | grep -A2 --line-buffered -E 'ButtonRelease' | grep --line-buffered -o 'button 1' > "$output" &

# Save a handle to the forked process
pid=$?

# Start a loop, as long as the file/output doesn't exist or has a zero-size, 
# stay in the loop
while [ ! -s "$output" ] ; do
    echo "seperate command"
    sleep 5
done

echo "We got something"
cat "$output"

# If you need to kill the original process, now's a good time
kill $pid

# Don't forget to delete the file
# 'trap' works well for doing this reliably.
rm "$output"
Improve this answer
3
  • Note that the while [ -z "$output" ] example doesn't work with xev, if you run what you show xev never exits, and the loop continues until you actively close thexev window. The script also fails, I think that's down to line buffering of xev itself, rather than grep, but I might be completely wrong there. Be that as it may, unfortunately neither approach works with the OP's example. Commented Mar 23 at 12:48
  • Nope, I was wrong, it is grep. Your second approach works with grep --line-buffered -o 'button 1'. But you need both greps to be line buffered. I can't get the first approach to work though. Commented Mar 23 at 12:52
  • Yes the xev command must be a blocking process because the first approach doesn't work. The second approach however does work! Thanks, The fork was what was needed. I was wondering if there's a way to get it to stop immediately since currently it has to finish the while loop before realising it should close. I did something with a bunch of: if [ -s $output ]; then break fi sleep 1 But it's not very elegant. Commented Mar 23 at 18:56
0

Here's a solution that puts the repeating xdotool command into the background, and then monitors xev for the relevant trigger. Once found it kills the background process and exits cleanly.

#!/bin/sh
#
(
    while sleep 10
    do
        xdotool mousemove 1401 1139 click 1
    done
) & 
cpid=$!

stdbuf -oL xev |
    awk '
        /^$/ { x = 0 }                 # reset for each new stanza
        /^ButtonRelease/ { x = NR }    # first trigger
        /button 1/ && x { exit }       # "button 1" in the same stanza
    '

kill $cpid
exit 0

The stdbuf -oL fools xev into outputting its informational messages line by line rather than buffered as would be more normal for a pipe.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.