Python as a scripting language. Alternative to bash script?
in [Python]
|
From: Lawrence D'Oliveiro on 23 Jul 2010 20:08 In message <slrni3478o.1qf.usernet(a)rutherford.ilthio.net>, Tim Harig wrote: > On 2010-07-05, Lawrence D'Oliveiro <ldo(a)geek-central.gen.new_zealand> > wrote: >> >> 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 ... But COM is an IPC architecture, which has nothing to do with GUI apps. Conflating the two leads to precisely the sort of inflexibility that is characteristic of GUIs. For example, things happening with the GUI on-screen while a script is running that are at best distracting to the user, or at worst vulnerable to breaking if the user accidentally presses a key or clicks in the wrong place. > 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. If those apps really were using AJAX, then why did you need to script a Web browser at all? You could just make direct HTTP requests to retrieve the data. > Automating GUI applications requires interal access to the program through > some kind of interface ... Some kind of interface that bypasses the GUI. This is why so many Open Source apps are structured as a GUI front end to a completely separate command-line tool (e.g. MPlayer). That way a script can use the latter without having to go through the former.
From: Lawrence D'Oliveiro on 23 Jul 2010 20:08 In message <mailman.301.1278423632.1673.python-list(a)python.org>, Michael Torrie wrote: > 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. Just be careful about properly escaping any special characters in the file names. See my other thread about escaping data, where some respondents have expressed a strong allergy to any form of embedding one language inside another.
From: Tim Harig on 24 Jul 2010 01:24
On 2010-07-24, Lawrence D'Oliveiro <ldo(a)geek-central.gen.new_zealand> wrote: > In message <slrni3478o.1qf.usernet(a)rutherford.ilthio.net>, Tim Harig wrote: > >> On 2010-07-05, Lawrence D'Oliveiro <ldo(a)geek-central.gen.new_zealand> >> wrote: >>> >>> 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 ... > > But COM is an IPC architecture, which has nothing to do with GUI apps. Not exactly. IPC allows you to send and receive information from another process; but, it doesn't give you internal access to the process. COM is much closer to an OO style of RPC. > Conflating the two leads to precisely the sort of inflexibility that is > characteristic of GUIs. For example, things happening with the GUI on-screen > while a script is running that are at best distracting to the user, or at > worst vulnerable to breaking if the user accidentally presses a key or > clicks in the wrong place. COM object have a visibility property that determines whether or not they are displayed to the user. >> 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. > > If those apps really were using AJAX, then why did you need to script a Web > browser at all? You could just make direct HTTP requests to retrieve the > data. The first and primary reason was that the application server required a client side SSL certificate. We didn't have access to a certificate that we could get to work Python's SSL or HTTPS modules. The second reason was that we had considerable difficulty figuring out how the server side interfaces worked from the slew of horrible Javascript. You really have to have seen it to know just what a mess this really was. Every call was literally wrapped in dozens of almost identical wrapper functions that you had to follow to attempt to figure out what was going on. Parts of the rendered form which looked like text field entries really weren't until a series of events took place to change them. They were used as flags indicating the state of various information. I really can't overstate how ugly this application really was. I was working on trying to figure out the serverside interface while my partner was trying to get an open SSL connection. By the time he gave up trying to convert our key to something we could use, I decided it was simpler just to use COM and internet explorer. It worked pretty well. >> Automating GUI applications requires interal access to the program through >> some kind of interface ... > > Some kind of interface that bypasses the GUI. This is why so many Open > Source apps are structured as a GUI front end to a completely separate > command-line tool (e.g. MPlayer). That way a script can use the latter > without having to go through the former. Which is great where the a separate backend exists. That isn't the case for a *huge* number of GUI applications; but, You don't always get to pick what you are going to need to automate. |