A GUI and a script should never be entangled if you ask me. There should be no coupling there. Everything script-related should run quite happily non interactive.
A GUI could drive a script however via the script's API.
I think ESR wrote about this in TAOUP (The Art Of Unix Programming) but I can't be bothered to dig through it now for the reference.
http://mstratman.github.com/cocoadialog/
Comes in very handy, along with Platypus for wrapping shell scripts:
I used it to notify me when a particular web page changed, but I think it could also be very useful for letting me know when a long-running script finished.
Some of the other tricks shown here also seem useful.
What's even better is that you can use BaCon to unify, and expand upon, pretty much everything mentioned in the article. BaCon is Basic Converter, created by Peter van Eerten, who also created GTK-server, which provides a stream-oriented interface to GTK, and which can be used with BaCon. Convert your shell scripts to BaCon, which then turns them into C, which is then compiled. Any calls to external commands can remain. Switching from shell scripts to BaCon is easy, you can stick with the tools you know, you can have as much GUI as you like (while remaining at the CLI), and the executables are lightning fast (compared to shell scripts).
