Jump to content

AutoIt v3.1.0 STD I/O Preview


DaveF
 Share

Recommended Posts

Hopefully this functionality will be available in the beta releases for AutoIt 3.1, but here's a preview in the case that you wish to play with it now. This is an unofficial release of AutoIt v3.1.0.15, and as such it has a 5 sec. nag at startup to remind you...

The extension provides reading from the STDOUT/ERR and writing to the STDIN streams of child processes created by the Run() function, by using the StdoutRead(), StderrRead() and StdinWrite() functions respectively. Options set in the script control which streams are redirected, and multiple child processes can be managed at the same time.

Find it http://www.autoitscript.com/fileman/users/public/DaveF/au3-stdio-3.1.0.15-public.zip.

The ZIP contains the unofficial AutoIt3 EXE, a CHM help file that describes the new functions (Under Function Reference | Process Management) and example scripts that demonstrate the functions.

Enjoy.

Edit: Wrong stream name

Edited by DaveF

Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Link to comment
Share on other sites

I just did a test with RunAs to send the password, but it fails.

It returns the following text:

---------------------------

STDOUT read:

---------------------------

Enter password for <DOMAIN>\<ACCOUNT>:RUNAS ERROR: Unable to accept input

---------------------------

OKĀ 

---------------------------

(I removed the domain name and account name from the text as a precaution.)

If you need me to give you more info, just ask me.

Link to comment
Share on other sites

I just did a test with RunAs to send the password, but it fails.

It returns the following text:

(I removed the domain name and account name from the text as a precaution.)

If you need me to give you more info, just ask me.

<{POST_SNAPBACK}>

RunAs doesn't allow passwords to be piped in by design. There's a tool called sanuR that lets you do so, but I see that it's no longer developed/supported (and the page refers you to try AutoIt instead)... :lmao:

Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Link to comment
Share on other sites

I've always wanted to mimic that "Sanur" app.

I'm disappointed that we can't do it, even with your version of AutoIt o:)

edit:

What am I whining about?! We have the RunAsSet function :lmao:

Forget what I said above.

Edited by SlimShady
Link to comment
Share on other sites

I've always wanted to mimic that "Sanur" app.

I'm disappointed that we can't do it, even with your version of AutoIt o:)

edit:

What am I whining about?! We have the RunAsSet function :lmao:

Forget what I said above.

In the cases where I've wanted both the console redirection and RunAs() for the child process I've RunAsSet() the credentials and had the script recursively run itself.

I've used bogus command line args as a test for whether the script was called recursively, but that disappoints me a little because it complicates making a script that uses command line arguments.

I couldn't think of any more elegant way to flag and test whether the the script had been called recursively; lock files and registry entries aren't good because script crashes can leave behind stale versions, an environment variable doesn't survive a profile change...

I haven't tried it, but I guess on NT versions of Windows you could create a named pipe with DllCall() and test for its existence with another DllCall()? I don't know if a limited user can create a named pipe...

Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Link to comment
Share on other sites

Haven't been able to create a named pipe yet, but you can determine if the desired pipe exists:

$call = DllCall($ourDll, "int", "WaitNamedPipe", "str", "\\.\pipe\lsass", "int", 0)
If @error = 1 Then
   MsgBox(0, "debug", "DllCall() failed...")
Else
   If $call[0] Then
      MsgBox(0, "debug", "Found named pipe!")
   Else
      MsgBox(0, "debug", "No such named pipe visible...")
   EndIf
EndIf

Regarding sanuR, I've thought it was strange that one puts sanuR on the command line following a | after Runas, I wonder if Runas reads the password info back through its STDOUT pipe in some way (like a named pipe...)

Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Link to comment
Share on other sites

Dave,

Could we add a mode so the output can use OutputDebugString?

I like to have the output to be capture by program like dbgview of www.sysinternals.com

<{POST_SNAPBACK}>

Do you mean that there should be an option to also write anything read/written to OutPutDebugString()? I can see how that would be helpful for, well, debugging. :lmao:

Are you thinking of something like:

StdinWrite wrote to process# 12345: howdy slim

StdoutRead peeked from process# 12345: OK

StdoutRead read from process# 12345: OK

StdinWrite wrote to process# 12345: quit

Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Link to comment
Share on other sites

Do you mean that there should be an option to also write anything read/written to OutPutDebugString()? I can see how that would be helpful for, well, debugging. :lmao:

Are you thinking of something like:

StdinWrite wrote to process# 12345: howdy slim

StdoutRead peeked from process# 12345: OK

StdoutRead read from process# 12345: OK

StdinWrite wrote to process# 12345: quit

<{POST_SNAPBACK}>

Yes can of debug which does not do anything if no debugviewer.

I prefer StdDbgWrite than if $traceon the StdOutWrite( ... o:)

not sure if StdOutWrite exist in your proposal

Link to comment
Share on other sites

...not sure if StdOutWrite exist in your proposal

Doh.

I've never thought of reading and writing to the streams of the parent process, that's how tardy I am. Though AutoIt is not a console app per-se the console I/O streams exist for the script process. I use them to provide inherited streams to child processes for the streams you don't care about; if you don't set the option to provide the STDERR stream for the child process then it uses the STDERR stream from the script.

That being the case and with the code already written, it should be trivial to make StdinRead(), StdoutWrite() and StderrWrite() functions that operate on the streams of the script process itself. There would exist the possibility of blocking I/O suspending the AutoIt process and disrupting timers, GUI message loops, etc. (providing another bullet for shooting one's own foot) if one tried to read from STDIN and no data had been written yet, but hey, we're all mature and responsible for our own actions, aren't we? :lmao:

Returning to your question, J-Paul, we could also implement a DebugWrite() function in AutoIt that would write messages only viewable in a debugger (using OutPutDebugString() ) or, if an option was set with AutoitSetOption(), write the message to the script's STDERR stream.

Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Link to comment
Share on other sites

ConsoleWrite() = StdOutWrite(), no?Ā  ConsoleWrite() wraps printf() which in turn writes to the current stdout handle.

No practical difference, no, except for maybe feedback.

If I was implementing StdoutWrite() in AutoIt I'd use WriteFile() in C++ and report back the number of characters written in the return; that's what I did for StdinWrite() because you don't necessarily know how the receiving pipe is going to behave...

Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Link to comment
Share on other sites

...report back the number of characters written in the return; that's what I did for StdinWrite()...

...or maybe not; StdinWrite() didn't correctly report a write size of 0 when it tries to write to a closed/invalid pipe, nor did it flag a closed pipe as invalid to prevent cleanup from trying to close the handle again, causing a runtime error.

Who writes this hobbyist crapcode? Is this what I'm paying for?! Where's the pride in craftsmanship?

Corrected, updated ZIP posted at the link above.

Edited by DaveF

Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Link to comment
Share on other sites

On behalf of Dave

Updated version uploaded to FTP dump, fixes StdinWrite()

- Didn't correctly report write size of 0 on closed/bogus handle

- Didn't invalidate closed handle on attempted read, cleanup in ~Stdio() would try to close handle again, causing runtime exception: invalid handle

this correction in included in the 3.1.0+ :lmao:

Link to comment
Share on other sites

I couldn't think of any more elegant way to flag and test whether the the script had been called recursively; lock files and registry entries aren't good because script crashes can leave behind stale versions, an environment variable doesn't survive a profile change...

You may also use the title of the hidden AutoIt window.

As stated in jon's FAQ 14. How can I make sure only one copy of my script is run?

Lock files by holding them open in (exclusive) write mode until lock condition is finished should work. I found those files will be always closed and freed sucessfull by the system even if the script/program crashes.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...