How to pipe variable to external program

9 posts in this topic

I am receiving a postscript print job via ConsoleRead() and assigning that data to a variable:

While True
       $sOutput &= ConsoleRead()

       If @error Then ExitLoop

At present... I am writing $sOutput to a file ( and then having ghostscript (a postscript file processor) process the file with this string (it converts ps to color tiff):

$iPID=RunWait(@ComSpec & " /c " & "C:\progra~2\gs\gs9.19\bin\gswin32c.exe -sDEVICE=tiff24nc -sOutputFile=c:\gstools\print.tif -dNOPAUSE -dSAFER -dBATCH c:\gstools\","", @SW_MAXIMIZE   )

I would like to skip writing the file and just pipe $sOutput directly to ghostscript.

I know how to configure ghostscript to receive piped input.  I do not know how to pipe a variable to an external program.

Any ideas?

Share this post

Link to post
Share on other sites

#2 ·  Posted (edited)


;~ Local $sOutput, $iPID = Run('"' & @ComSpec & '" /c ' & 'C:\progra~2\gs\gs9.19\bin\gswin32c.exe -sDEVICE=tiff24nc -sOutputFile=c:\gstools\print.tif -dNOPAUSE -dSAFER -dBATCH c:\gstools\', '', @SW_MAXIMIZE, 8)
;~ Do
;~  Sleep(10)
;~  $sOutput &= StdoutRead($iPID, False, False)
;~ Until @error
;~ ; $sOutput = StringStripWS($sOutput, 7)
;~ MsgBox(32, "Output", $sOutput)

Local $sOutput, $iPID = RunWait('"' & @ComSpec & '" /c ' & 'C:\progra~2\gs\gs9.19\bin\gswin32c.exe -sDEVICE=tiff24nc -sOutputFile=c:\gstools\print.tif -dNOPAUSE -dSAFER -dBATCH c:\gstools\', '', @SW_MAXIMIZE, 8)
$sOutput = StdoutRead($iPID)
MsgBox(32, "Output", $sOutput)


Edited by Trong
I think I do not know what you mean!


Share this post

Link to post
Share on other sites

If your AutoIt script is reading PostScript generated somewhere else, and then calling GhostScript, are you therefore calling AutoIt itself with some command like

    "some\path\to\a-program-that-generates-PS.exe" | "AutoIt3.exe" "your-script.au3"

because if you're not, I don't see how your AutoIt script is able to read PS data from    ConsoleRead() ?


If that IS what you're doing, why don't you instead use:

    "some\path\to\a-program-that-generates-PS.exe" | "your-ghostscript-command..."

and if there's anything that AutoIt needs to do, run that afterwards, once the GS command is complete?

Share this post

Link to post
Share on other sites

JeremyNicoll... you are correct.  AutoItScript is reading PostScript from a stream generated by PrintMon which is a printer port monitor.

The reason that I need autoitscript in the middle is to generate a random name for the print job and also to use ghostscript to convert it to either pdf or TIFF depending on a number of factors.

So... If I use the "some\path\to\a-program-that-generates-PS.exe" | "your-ghostscript-command..." ...which I can... I can't accomplish the above.

Share this post

Link to post
Share on other sites

#5 ·  Posted (edited)

OK, rather than having AutoIt do what you posted, have it generate the random name etc, then build the whole command string from various parts, then have AutoIt issue the whole command (ie the thing that generates PS, the pipe, and the GS part). 

Edited by JeremyNicoll

Share this post

Link to post
Share on other sites

I see you point.... but what I have built is a virtual printer.... So... someone, whereever they are on the network, and whether or not they are in Word, Excel, Acrobat, Outlook, etc... if they are wanting to archive the document they are looking at... they just print to the "Virtual Printer".

So... at that point... a print job has been generated by who-knows-what or where... but the user wants to archive it.

So now... in it comes to AutoIt... and I can run all kinds of analysis... that it would take years to train for and many more to audit for.... and then save it properly, in the proper format and proper folder... maybe even with a barcode stamp.

It is working perfectly now... if I just write the variable to a file and then have gs pick up the file.... I was just wanting to skip that step and directly feed gs with the variable.

Share this post

Link to post
Share on other sites

In your virtual printer def, does it write to a 'port' which is the AutoIt script? 

Why, if the file coming out of the virtual printer is a printable file, are you pushing it through GS at all?  Why not archive it in the format it comes out of the virtual printer?  You could save time...  It could be converted to PDF later on, if and when someone wants to view/print it.

As a side issue, I think your code has a separate problem, which is that you've hardcoded the names of the intermediate files, eg    But unless that's inside a folder which has eg a datestamp and/or processs-id and/or username component, separate files created by the same user or by a failed previous use of this mechanism, or another one happening at the same time, will trip over each other.

Share this post

Link to post
Share on other sites

#8 ·  Posted (edited)

AutoIt is an integral part of the "Virtual Printer".

So... the print spooler writes to a virutal port (RPT set up by Redmon ... I misspoke and called it PrintMon above)

Redmon then picks up the stream and sends it to any external application in this case autoit... but it could be gs) along with whatever command line parameters.  I use AutoIt to analyse the print stream and command line parameters.. and then name and process.

 gs then convert the print stream to TIFF and/or PDF... that is because it needs to be OCR'd, sorted, filed, etc.

It is then instantly available, enterprise wide, as a resource to our EDMS solution, of course, properly tagged and indexed.

Edited by ccbamatx
More Detail

Share this post

Link to post
Share on other sites

What happens if you have your AutoIt script NOT read the print stream, but merely build a GS command and issue it?  Then GS, when it reads from standard input, might see the original print stream (that's still waiting to be consumed, having not been read by AutoIt).   I have a feeling that the GS command might need to be told that it has to inherit the standard input file handle that was defined for AutoIt, though, and I don't know if that's possible.

Share this post

Link to post
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