0

I'd like to issue 2-3 rapid, consecutive alerts in an automated script running in the standard terminal app.

I am already able to issue a single alert with echo -e '\a'. However, when I try to issue multiple alerts with echo -e '\a\a', there is a noticeable (~1 second) lag between the two alerts.

If I enter commands interactively, I am able to trigger rapid, consecutive alerts by entering echo -e '\a', pressing the up arrow to retrieve the last command, and pressing enter again. There is no noticeable delay between the first and second alert beyond the time it takes me to enter the second command.

However, I'd like to be able to do this from an automated script, so I'd like to be able to avoid the delay in between alerts without having to enter commands manually via keyboard.

Specs: MacBook Pro (14-inch, 2021) / Apple M1 Pro chip / macOS Monterey 12.3.1

The motivation is to be able to signal failure/success of a long-running command being executed remotely. When running these types of commands locally I use a wrapper around say that tells me via text-to-speech whether the command has succeeded or failed. For remotely-executed commands where text-to-speech is either not an option or not worth the trouble, I'd instead like to be able to use the number of alerts to know the status of the command, without a long delay between multiple alerts.

1 Answer 1

0

It seems that you can't run two beep exactly in the same time.

You have to put a little pause between two beep.

I propose you the following function to run the amount of beep you want :

beepFunction () {
        for ((i=0 ; i<$1 ; i++))
        do
                echo -e "\a"
                sleep 0.2
        done
}

Here we use "sleep" to do a pause of 0.2 seconds.

Then you can call the function in this way :

# 4 beep
beepFunction 4

If you prefer a one-line solution, you can use this code :

# 4 beep (0 to 3)
for v in {0..3} ; do echo -e "\a" ; sleep 0.2 ; done
2
  • This doesn't work on my machine. I've tried similar approaches that artificially inject pauses in various ways between the two alerts; the same delay persists. Apr 18, 2022 at 16:33
  • Actually, it seems like there's an upper bound on how much time needs to elapse for a pause to be injected in between the two. If I try to issue the alerts with two or more seconds in between them (using the sleep technique in this answer), then there is no delay. But if the time is less, like one second, then there's a noticeable difference for the second alert between when the terminal flashes and the bell sound is played. Apr 18, 2022 at 16:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .