AutoIT CLI app output

[nitro322]

I'm writing an AutoIt script that will be used from the command line, and only the command line. It itself will then be scripted to run on remote computers. I need the AutoIt script to print output to the console from which it was called rather than to a new dialog box, however I cannot figure out how to make this happen.

As an example, if I write a program to output the hostname of a computer, the execution and output from the command line should look like this:

C:\Scripts> hostout.exe
Hostname is bigdog

C:\Scripts>

How can I do this? I can't figure out anyway to make any of the standard output functions do this. I also tried using some of the new functions in the beta (ConsoleWrite, StdoutRead, StdinWrite, etc.), but couldn't figure out how to make any of them work, either.

Surely this is possible, right? Any pointers?

Thanks.

[DaveF]

ConsoleWrite is actually doing what you want, but there's a problem; compiled AutoIt scripts are not considered console applications by Windows. If you run your compiled script by itself in a DOS window you'll see no output because the Windows shell disconnects the STDOUT pipe from non-console applications when they are spawned. This is why you don't see any output in your tests.

If your compiled AutoIt script will be spawned by another process which reads its output then things will work as expected.

[LxP]

Just to add to what Dave has stated, if hostout.exe is an AutoIt script using ConsoleWrite() then calling it in this way will yield this result:

C:\Scripts>hostout.exe

C:\Scripts>

However calling it in this way will yield this result:

C:\Scripts>hostout.exe > output.txt

C:\Scripts>type output.txt
Hostname is bigdog
C:\Scripts>

which may or may not suffice.

[nitro322]

Hmm... That explanation makes sense, though it's not exactly what I was hoping to hear. :-(

I don't suppose there's any way to make Windows recognize and AutoIt .exe as a console app? or, conversely, to make AutoIt generate a console-specific .exe?

If not, it'd be a very nice feature to add.

Thanks for the responses.

[DaveF]

Hmm...  That explanation makes sense, though it's not exactly what I was hoping to hear.  :-(

I don't suppose there's any way to make Windows recognize and AutoIt .exe as a console app?  or, conversely, to make AutoIt generate a console-specific .exe?

If not, it'd be a very nice feature to add.

Thanks for the responses.

<{POST_SNAPBACK}>

I don't have an easy way to make the change, but the only difference between a win32 console app and a GUI app is that somewhere in the Portable Executable header for the EXE there's a string of 3 characters, either CUI for a console app or GUI for a gui app. If you open your final EXE file with a binary editor and change the G to a C you'll have a console app...

[Gigglestick]

I don't have an easy way to make the change, but the only difference between a win32 console app and a GUI app is that somewhere in the Portable Executable header for the EXE there's a string of 3 characters, either CUI for a console app or GUI for a gui app. If you open your final EXE file with a binary editor and change the G to a C you'll have a console app...

This didn't work on the EXE the Aut2Exe created, but that's been UPX'd. I also tried decompressing Aut2Exe's EXE and found that if you try to run the resulting EXE it says "Unable to open the script file." I tried looking for "GUI" in the Hex code, but every instance seemed to be a built-in GUI function name. This is irrelevant anyway because the script seems to have been removed during decompression.

It would be interesting to have a console version of AutoIt.exe, which could be compiled using something like "Aut2Exe /console /in file.au3", which wouldn't have any GUI stuff in it. Not having GUI stuff in the EXE would scale down the size as well. Would it be easy to change the VC project to produce both AutoIt.exe's from the same code?

Edited August 22, 2005 by c0deWorm

[DaveF]

Now after having shot my mouth off, I've tried to go back and find my source re: the 3-char GUI/CUI thing, and of course I can't find it.

What I did find was the Subsystem member of the Optional Header for Portable Executables, which is a single numeric value which tells the shell how to handle the EXE. For a Windows GUI EXE like AutoIt it's set to 2, for a console app it's set to 3.

For what it's worth, I can verify that if you edit AutoItSC.bin with an EXE editor and make the above change of the Subsystem member from 2 to 3, that any subsequent compiled script that you make will behave like a console app; N.B. that doing so will probably get you unpredictable results for any GUI that you try to make...

[Valik]

DaveF, that sounds extremely dangerous. Did you test the modification by passing command line parameters to the hacked AutoIt? I would be amazed if it works. The entry point for AutoIt is expecting a signature of "HINSTANCE, HINSTANCE, LPSTR, int". I admit that I don't know how the loader works exactly in Windows but I would expect it to try to pass an "int, char**, char**" if it thinks its a console app and that would be disastrous.

[DaveF]

DaveF, that sounds extremely dangerous.  Did you test the modification by passing command line parameters to the hacked AutoIt?  I would be amazed if it works.  The entry point for AutoIt is expecting a signature of "HINSTANCE, HINSTANCE, LPSTR, int".  I admit that I don't know how the loader works exactly in Windows but I would expect it to try to pass an "int, char**, char**" if it thinks its a console app and that would be disastrous.

<{POST_SNAPBACK}>

Thanks, Valik, as always for keeping it real.

Yes indeed, caveat h4><0r, YMMV, and it's probably stupid to do this in a production environment. With that said, this guy has made a tool to do what I was describing, and the article seems to corroborate that the only change is to the Subsystem member in the Optional header. You're still playing with fire.

[Valik]

Thanks, Valik, as always for keeping it real.

Yes indeed, caveat h4><0r, YMMV, and it's probably stupid to do this in a production environment. With that said, this guy has made a tool to do what I was describing, and the article seems to corroborate that the only change is to the Subsystem member in the Optional header. You're still playing with fire. 

<{POST_SNAPBACK}>

This is a very strange way of solving a problem. I would of thought writing a console application which in turn runs the GUI application and connects to its std streams would be the way to go. In other words, just create a simple wrapper. It shouldn't be more than a hundred lines of code for a generic wrapper like that.

[DaveF]

This is a very strange way of solving a problem.  I would of thought writing a console application which in turn runs the GUI application and connects to its std streams would be the way to go.  In other words, just create a simple wrapper.  It shouldn't be more than a hundred lines of code for a generic wrapper like that.

<{POST_SNAPBACK}>

Or a batch file?

I'm just trying to keep an AutoIt context...