Getting StdOut from ConsoleWrite in Uncompiled script

[jvanegmond]

Solution: How to read standard stream out (StdOut) from ConsoleWrite in an uncompiled script

I'm looking for a way to make one host script start up and communicate with several uncompiled scripts. The uncompiled scripts are modules which are ideally written by other developers. Therefore IPC on the module side has to be simple and fast to test and debug. Put simply, if the module can exist of ConsoleWrite and get parameters from $CmdLine it will be perfect. Assume AutoIt binaries from installer are available.

Ideally, IPC would fit these requirements:

- Uses no libraries or includes on the module side (works with ConsoleWrite and $CmdLine or similar)

- No files or disk I/O is being used

- It doesn't involve compiling of modules before we can get output from them

Example module (ideally):

$ping = Ping($CmdLine[1])
If @error Then
    ConsoleWrite("Ping to " & $CmdLine[1] & " failed with error code " & @error & @CRLF)
Else
    ConsoleWrite($CmdLine[1] & " is available" & @CRLF)
EndIf

Edit: Changed title to better fit the solution pointed out below.

Edited October 11, 2010 by Manadar

[PsaltyDS]

This topic sounds familiar, haven't we been here before?

Can your module side just write to a control on the host script's GUI (doesn't even have to be visible):

$ping = Ping($CmdLine[1])
If @error Then
    ControlSend("Host Script GUI", "", "Edit1", "Ping to " & $CmdLine[1] & " failed with error code " & @error & @CRLF)
Else
    ControlSend("Host Script GUI", "", "Edit1", $CmdLine[1] & " is available" & @CRLF)
EndIf

P.S. If disk access is allowed, you can just write to a shared log file, or SQLite DB, etc.

Edited October 8, 2010 by PsaltyDS

[JohnOne]

For comunication of this nature, I use the method shown in this example by GreenCan.

[jvanegmond]

Psalty, the control send method is the closest to what I want atm, but I rather make the coupling between the host and client a little less tight. Using ControlSend means the module has to know where to find the host which is undesirable. Shared memory is a pretty heavy library for modules to include, so that's a definite no.

Edit: I see that at some point you have to define a specific interface between the host and the module and what I'm asking for is close to programming magic. Keeping the interface as small as possible and in native AutoIt are notable benefits. Looking at it that way, controlsend vs consolewrite is very unfavorable.

Basically, what I need is AutoIt3.exe to run my scripts as-if they are CUI and I can use ConsoleWrite to write to the standard output stream. Since I know that's just a stupid thing to ask for, I describe my problem in a broader sense and hope someone to shed some more light on the issue. (So no, we haven't been here before.)

Edited October 8, 2010 by Manadar

[JohnOne]

Perhaps I'm missing something, but that example is pure autoit as far as I can tell, the only #include is guiconstants, and thats because it has a gui.

[jvanegmond]

JohnOne, I didn't say it didn't meet the native AutoIt requirement only. I'm not going to use that method since there is a tighter coupling than what I want and it's more complicated than ControlSend. See post #4 for more in depth.

Edited October 9, 2010 by Manadar

[Confuzzled]

Can't you spool your command line to temporary batch files and then launch them with parameters and pick up the parameters inside the batch file?

Remember the "%0", "%1", and ">>" options?

Alternatively, cannot you create 'daughter' AutoIT scripts, and then launch them, uncompiled, from your 'master' (compiled) script?

[jvanegmond]

Can't you spool your command line to temporary batch files and then launch them with parameters and pick up the parameters inside the batch file?

Remember the "%0", "%1", and ">>" options?

Alternatively, cannot you create 'daughter' AutoIT scripts, and then launch them, uncompiled, from your 'master' (compiled) script?

Thank you, your reply led me to the solution. It didn't occur to me that I could use a compiled master script to run uncompiled scripts and capture output from them. For my own convenience, I have made a little wrapper executable which executes the uncompiled script.

wrapper.au3

#AutoIt3Wrapper_Change2CUI=y
$h = Run(@AutoItExe & ' /AutoIt3ExecuteScript "' & $CmdLine[1] & '"', "", @SW_HIDE, 2)
While 1
    $d = StdoutRead($h)
    If @error Then ExitLoop
    ConsoleWrite($d)
WEnd

I compile wrapper.au3 to a Console application (I have to manually start Compile script to exe and check the Console? checkbox),

and I run it simply like:

wrapper.exe test.au3

And the ConsoleWrite output from test.au3 appears which can be captured in my uncompiled server. :]

Edit: The above example doesn't include /StdErrOut which I added later

Edited October 11, 2010 by Manadar

[jchd]

P.S. If disk access is allowed, you can just write to a shared log file, or SQLite DB, etc.

Sharing an SQLite DB over a network is not recommended. The problem is that, as per today, no network file system (PC, Mac, whatever, Windows, Unix or other, NFS, SMB or other) implements shared file locking correctly in all cases and since an application layer like SQLite relies on very precise and consistent implementation of various file lockings at potentially high rate, the result can be unavailable, wrong or desastrous at any time.

[PsaltyDS]

@jchd: Yeah, I've seen you bring that up before, and I don't doubt it's true. My favorite answer for that is for the server side script, with direct disk access not over the network, be the only one to actually write to the DB. All the clients just write little transaction files to the share with time-tag unique file names.

Or, of course you could install a full size heavy weight DB engine, but Manadar clearly doesn't want to go with heavy solutions here.

[jchd]

The issue is even a little worse: SQLite (as any other DB engine BTW) needs file locking even for reads, so that doesn't keep you safe from getting spurious and hard to recover "DB is locked" status forever, for instance, or reading dirty (or phantom) data. Of course having only a local writer won't corrupt the DB itself, but the overall behavior is likely to be unreliable.

A nice solution would be to use a client/server wrapper for SQLite. There are several freely available ones, all referenced on the SQLite website. This extra layer makes remote useage as solid as DB2 or Oracle but at no cost at all.

Switching to some full-fledges client/server engine isn't an option in many circonstances.

[saywell]

Would MYsql be better for this - and there's a UDF, IIRC.

William

[jchd]

It all depends on your requirements. MySQL isn't free for all uses, isn't portable, isn't embeddable, requires non-trivial installation, requires administration, ...

You can embed SQLite code in potentially every application on myriad of platforms without any install, fancy administration a.s.o., yet having the full power of a fast SQL engine to access your data.

It's quite probable you own a decently recent cellphone or smartphone, PDA, GPS or such. In allmost all of them you have an SQLite DB, which some of these devices allow you to access, query, save etc. I wouldn't bet MySQL could do the same. Same situation for every instance of Firefox, and many, many other common application (and devices).

[SmOke_N]

It all depends on your requirements. MySQL isn't free for all uses, isn't portable, isn't embeddable, requires non-trivial installation, requires administration, ...

You can embed SQLite code in potentially every application on myriad of platforms without any install, fancy administration a.s.o., yet having the full power of a fast SQL engine to access your data.

It's quite probable you own a decently recent cellphone or smartphone, PDA, GPS or such. In allmost all of them you have an SQLite DB, which some of these devices allow you to access, query, save etc. I wouldn't bet MySQL could do the same. Same situation for every instance of Firefox, and many, many other common application (and devices).

Funny you mention the servers, I was looking into them myself. The sqlitening one was the one I think that really caught my interest.

It's written in a proprietary language though, so kind of a pain to code around unless you explicitly use what they've already created for you or purchase the right to use the language it was written in.

[jchd]

Yep, SQLitening is a PowerBasic offspring for SQLite. While both have good reputation for robustness and consistency, they are essentially payware contributions in the end, due to the profit-aimed nature of PowerBasic.

But SQLitening isn't the only client/server wrapper around, most if not all the others being freely available as C/C++ source code with few licence limitation, if any.

Another widely used possibility is to make the system as a web service (Apache, PHP[DO] and such) , but we're now outside AutoIt natural domain.

Apologies to the OP for somehow sneakily hijacking his/her thread.

[robertocm]

On sábado, 09 de octubre de 2010 at 10:20 AM, jvanegmond said:

I could use a compiled master script to run uncompiled scripts and capture output from them.

Sorry for posting in an old thread, but i'm learning from this and testing some small variation from example at #8

Step 1: compile this simple script as 'wrapper.exe'

#pragma compile(AutoItExecuteAllowed, true)
$iPID = Run(@AutoItExe & ' /AutoIt3ExecuteScript "' & $CmdLine[1] & '"', "", @SW_HIDE, 8)

Step 2: create a .au3 file in same folder named as 'example_child.au3'

MsgBox(0, "It Works", "Hello World, " & $CmdLine[1])
ConsoleWrite("Hello World from ConsoleWrite!, " & $CmdLine[1])

Step 3: create another .au3 named as 'test_main.au3'

#include <Constants.au3>

Local $iPID = Run('wrapper.exe /AutoIt3ExecuteScript "example_child.au3"' & ' "Buenos Días"', @ScriptDir, @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD)

ProcessWaitClose($iPID)
Local $sOutput = ""
$sOutput = StdoutRead($iPID)
MsgBox(0, "Stdout Read:", $sOutput)
ConsoleWrite($sOutput & @CRLF)

;this is another possibility
;While 1
;    $sOutput = StdoutRead($iPID)
;    If @error Then ExitLoop
;    ConsoleWrite($sOutput)
;WEnd
;ConsoleWrite(@CRLF)

Step 4: open test_main.au3 with the editor and execute: output from 'example_child.au3' should appear in the console.

Edited December 25, 2016 by robertocm