Make my Mac beep me when it's finished.

May 11, 2006 3:59 AM

Help me make my other Mac, in the other room, beep me when an app has finished what it's doing.

I have two Macs. The one in the living room is for browsing. The other one, down the hall, is where I do things like burning DVDs. It's not online.

So, if burning a DVD takes 20 minutes or so, I forget about it. A couple of hours later I remember and start burning the next one. So about an hour's work can take all day. And I can't be forever walking down the hall to see how it's going.

So, there must be some way I can run a script which monitors ps or top or something, right?

Every minute it could check and if Disk Utility's CPU usage was at 0.00%, then it's finished. And the computer would start quietly beeping. There's still some BELL character you can print to make it beep, right? Am I going to have problems with false positives, readings of zero for a split second?

For all I know there's actually shiny-GUI software which will do this, but I've never heard of it and can't think how to search. And I don't need it. I'll happily start the app, then type

beepwhenfinished 'Disk Utility'

or something.

posted by AmbroseChapel to computers & internet (20 comments total)

I wrote a script like this to monitor when an application has died and restart it. If you don't find a more robust solution here, I'll hack it up to do what you want. Email in profile.
posted by bonaldi at 4:56 AM on May 11, 2006

I don't know if Growl does or could be made to do specifically what you mention, but it's in the right ballpark!
posted by kimota at 5:02 AM on May 11, 2006

Hmm.

Maybe (this isn't tried on MacOS yet....)

From the shell (this is /bin/sh, not (ickbleagh) csh. IIRC, tiger uses bash as the default shell, that'll work as well.

FOO=1; while [ $FOO != "0.0" ] do $FOO=`ps -axo %cpu=c -o command=n | grep 'Disk Utility" | cut -b 1-4`; sleep 1; done; while true do echo "^G^G^G^G^G"; sleep 1; done

(The ^G above is "Control-G". Control-G is ASCII BEL, it rings the bell. This should beep.)

Note that the test I'm using here is not a mathmatical test, it's a string comparision. Why? Because I'm not sure if the OS/X shell's test will cope with non-integers correctly.

Issue: Does ps work the same way as mine? Probably, given Jordan Hubbard is working at Apple, so many of the command line utilites speak FreeBSD.

Ideally, the right way to do this is to find a burning utility that works from the command line. When I get to the office and open up the notebook, I'll check for burncd or if Disk Utility has any command line features.

I'll also note that this is a oneliner, not a production script.
posted by eriko at 5:04 AM on May 11, 2006

DVD burning is pretty predictable as to how long it's going to take -- it's more or less directly proportional to the amount of data (duh, right?). How about starting the burn, looking at the estimated time remaining, add a minute or two, and then setting up a kitchen timer?

Yeah, it's low tech and doesn't carry over to other tasks of inteterminate duration, but it'll sure work DVD burning.
posted by pmbuko at 5:31 AM on May 11, 2006

If you can arrange for the app to actually quit when it finishes burning (seems like it might be an option), you do something like this:

while (killall -s [name of burning app] >/dev/null) do sleep 10; done; echo ^G

killall recognizes processes by name, has nonzero exit status if the program isn't actually running. The echo will make a single 'bonk' sound at you so you might replace that with something noisier.
posted by Wolfdog at 5:35 AM on May 11, 2006

Radical solution, pmbuko. I don't even have a kitchen timer! Good point though.

I don't have Tiger either by the way (still on Panther, should have said), and prefer tcsh, but anyway, yes, that looks good eriko. I'll try it ... hmm.

It's not working for me in in bash or sh.

I get

syntax error near unexpected token `done'

Also, I think we've got mixed single and double quotes around Disk Utility?
posted by AmbroseChapel at 5:49 AM on May 11, 2006

Thanks Wolfdog but no, it can't quit when finished. Good idea otherwise.
posted by AmbroseChapel at 5:52 AM on May 11, 2006

Wolfdog's answer, as well as a similar script written in AppleScript instead of csh, will eat 10-20% of the CPU in monitoring and parsing processes. If your application of interest fires off distributed notifications as its status changes, it is possible to write a threaded app that will listen for those notifications in an efficient way.
posted by Mr. Six at 5:59 AM on May 11, 2006

By the way

ps -axo %cpu=c -o command=n

seems to be doing what you expect, i.e. a list of running processes with cpu usage numbers before them.
posted by AmbroseChapel at 5:59 AM on May 11, 2006

will eat 10-20% of the CPU
Um, no. Try it. Monitor it.
posted by Wolfdog at 6:11 AM on May 11, 2006

How about something as simple as

burn_dvd_command_line && echo ^G
posted by primer_dimer at 8:39 AM on May 11, 2006

To take eriko's ball and run with it,

#!/bin/sh
cpu=1
while [ $cpu -gt 0 ]; do
cpu=`ps -axo %cpu=c -o command=n | grep "[/]$1 " | cut -d'.' -f1`
sleep 60
done
while true; do
say beep # or perhaps say "$1" is finished
sleep 10
done

Save that as beepwhenfinished and give it the ol'

chmod +x beepwhenfinished
posted by Prince Nez at 8:47 AM on May 11, 2006

Not the best solution, but I use a perfectly legal copy of Toast Titanium to burn stuff, and it has plenty of "I'm done! LOL" audible alerts. I use it for exactly what you're looking for.
posted by cyrusdogstar at 8:59 AM on May 11, 2006

This is the kind of thing Perl's good at, so:

perl -e 'sleep 1 while `ps -axo %cpu -o command | grep "[/]Disk Utility"` !~ / 0.0 /; print "^G^G^G^G"'

To type the ^G character at the command line, type ctrl-v ctrl-g.
posted by nicwolff at 10:12 AM on May 11, 2006

Oh and thanks to eriko for the ps formatting flags and Prince Nez for the nifty [/] grep trick - how did I not know that?!
posted by nicwolff at 10:16 AM on May 11, 2006

Thanks for all the suggestions like the command-line burner and the use of an application which beeps.

I should make a couple of things clearer I guess -- it's not just DVD burning. As I said, it's "things like DVD burning". So I really was looking for a generalised solution which I could use on any application which ran long processes.

The solution posted by Prince Nez seems to be working, although it's complaining

line 3: [: -gt: unary operator expected

Just to be clear, I'm typing

./bwf <name of app>

as in

./bwf VLC.app

while VLC plays a video, and when the video's done, the mac says "beep" over and over.

I saved it as "bwf" because it just seems more Unix-y...
posted by AmbroseChapel at 1:50 PM on May 11, 2006

nicwolf, your solution successfully monitored the process but I didn't get any sound. I'm not sure the ^G thing works on OS X?
posted by AmbroseChapel at 2:15 PM on May 11, 2006

I researched Growl by the way and while it's a brilliant idea, it's not supported by any of the apps I've got in mind.

The combination of Growl and Observation Post might somehow do it, and if it was just burning I needed the notifications for I could use the Growl-aware DiskBlaze, but I'm happy with the shell script myself.
posted by AmbroseChapel at 4:28 PM on May 11, 2006

The solution posted by Prince Nez seems to be working, although it's complaining
line 3: [: -gt: unary operator expected

That'll happen if the $cpu variable is empty, which is anytime the grep comes up with nothing. Make sure you get the name of the app right, and quote any apps with spaces in their names

bwf iTunes
bwf 'Disk Utility'
posted by Prince Nez at 7:36 PM on May 11, 2006

Catching up on this...

Hmm, I definitely am quoting where I need to quote. I was anticipating that in the OP!

That error message only occurs after the app has finished, once, not every time it checks.

I've learned in using it that Disk Utility can have periods of Zero CPU use which give false positives, for instance when a CD has been burnt, then gets mounted, then verified, usage is briefly zero during the mounting stage.

But I think I know enough now to run a double-check and see if $cpu has been zero twice in two minutes, that should be enough to iron out that bug.
posted by AmbroseChapel at 5:22 PM on May 14, 2006