Python as a scripting language. Alternative to bash script?

[Tim Harig]

On 2010-07-24, Lawrence D'Oliveiro <ldo at geek-central.gen.new_zealand> wrote:
> In message <slrni3478o.1qf.usernet at rutherford.ilthio.net>, Tim Harig wrote:
>
>> On 2010-07-05, Lawrence D'Oliveiro <ldo at 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.