Re:Spicing unix shell scripts
by bwarp on Sunday February 19, 2012 @03:10PM
(#3610250)
The only thing I do and would use there is "logger". The rest is about showboating.
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.
Re:Spicing unix shell scripts
by tikhonj on Sunday February 19, 2012 @03:38PM
(#3610322)
I've found the notify-send command to be really useful for some of my random 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.
Re:Spicing unix shell scripts
by ThaddeusQuay2 on Sunday February 19, 2012 @02:50PM
(#3610171)
"There are some misconceptions that shell scripts are only for a CLI environment. You can easily use various tools to write GUI and/or network (socket) scripts under KDE or Gnome desktops. With the following tools you can build powerful, interactive, user friendly UNIX / Linux bash shell scripts."
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).
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:
http://sveinbjorn.org/platypus
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.
More portably, you can use something like netcat or socat.
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).
http://basic-converter.org
http://en.wikipedia.org/wiki/GTK-server