Python as a scripting language. Alternative to bash script?
in [Python]
|
From: Tim Harig on 5 Jul 2010 14:02 On 2010-07-05, Lawrence D'Oliveiro <ldo(a)geek-central.gen.new_zealand> wrote: > In message <op.ve06nlvia8ncjz(a)gnudebst>, Rhodri James wrote: >> Classic Unix programming is a matter of stringing a bunch of tools >> together with pipes to get the output you want. This isn't a great >> paradigm for GUIs (not without tweaking that hasn't really been done), but >> then again it was never meant to be. > > I???ve never come across any system where you could string together multiple > GUI apps, or even multiple GUI operations in the same app, in any sensible > or effective way at all. GUIs just aren???t designed to work that way. You can if they are designed to be used externally. COM is an execellent example of this as is script-fu and any number of other technologies that allow external access to the subroutines or automation capability of a GUI application. The problem is not that it cannot be done; but, that it must be explicilty designed to be used this way. I have worked with complex business process automation centered around Excel and I have automated some really ugly AJAX style web based applications that would only work inside of IE6 by accessing IE through its COM interface. > The command line (or scripting, the difference isn???t that important) remains > the only workable way to string together complex combinations of simpler > operations. The difference is that it is almost always possible to automate using text based applications, even when the author of the software never designed the software to be scripted. Text based IO streams are easy to capture and manipulate. Automating GUI applications requires interal access to the program through some kind of interface and, ideally, decent documention of the interface, something that is missing from many, if not most, GUIs. Anything else relies on ugly and, generally fragile, mechanisms to intercept the programs output and send event triggers to the application. The recent thread to automate Minesweeper by processing its screenshot is an example of this.
From: Emile van Sebille on 5 Jul 2010 14:43 On 7/5/2010 11:02 AM Tim Harig said... > Automating GUI applications requires interal > access to the program through some kind of interface and, ideally, decent > documention of the interface, something that is missing from many, if > not most, GUIs. Anything else relies on ugly and, generally fragile, > mechanisms to intercept the programs output and send event triggers to > the application. I've been doing the 'anything else...' stuff for years now without issue, so ugly, yes, but fragile, not really. Unless you let users on the same machine... Emile
From: sturlamolden on 6 Jul 2010 06:12 On 28 Jun, 19:39, Michael Torrie <torr...(a)gmail.com> wrote: > In python I could simply take the output of "ps ax" and use python's > own, superior, cutting routines (using my module): > > (err, stdout, stderr) = runcmd.run( [ 'ps', 'ax' ] ) > for x in stdout.split('\n'): > print x.strip().split()[0] Or you just pass the stdout of one command as stdin to another. That is equivalent of piping with bash.
From: Michael Torrie on 6 Jul 2010 09:40 On 07/06/2010 04:12 AM, sturlamolden wrote: > On 28 Jun, 19:39, Michael Torrie <torr...(a)gmail.com> wrote: > >> In python I could simply take the output of "ps ax" and use python's >> own, superior, cutting routines (using my module): >> >> (err, stdout, stderr) = runcmd.run( [ 'ps', 'ax' ] ) >> for x in stdout.split('\n'): >> print x.strip().split()[0] > > Or you just pass the stdout of one command as stdin to another. That > is equivalent of piping with bash. Consider this contrived example: tail -f /var/log/messages | grep openvpn While it's possible to set up pipes and spawn programs in parallel to operate on the pipes, in practice it's simpler to tell subprocess.Popen to use a shell and then just rely on Bash's very nice syntax for setting up the pipeline. Then just read the final output in python. If you set the stdout descriptor to non-blocking, you could read output as it came.
From: member thudfoo on 6 Jul 2010 16:35
On Tue, Jul 6, 2010 at 6:40 AM, Michael Torrie <torriem(a)gmail.com> wrote: > On 07/06/2010 04:12 AM, sturlamolden wrote: >> On 28 Jun, 19:39, Michael Torrie <torr...(a)gmail.com> wrote: >> >>> In python I could simply take the output of "ps ax" and use python's >>> own, superior, cutting routines (using my module): >>> >>> (err, stdout, stderr) = runcmd.run( [ 'ps', 'ax' ] ) >>> for x in stdout.split('\n'): >>> print x.strip().split()[0] >> >> Or you just pass the stdout of one command as stdin to another. That >> is equivalent of piping with bash. > > Consider this contrived example: > > tail -f /var/log/messages | grep openvpn > > While it's possible to set up pipes and spawn programs in parallel to > operate on the pipes, in practice it's simpler to tell subprocess.Popen > to use a shell and then just rely on Bash's very nice syntax for setting > up the pipeline. Then just read the final output in python. If you set > the stdout descriptor to non-blocking, you could read output as it came. > -- > http://mail.python.org/mailman/listinfo/python-list > Is this a discussion about the pipes module in the std library? |