How to pipe variable to external program

[ccbamatx]

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

While True
       $sOutput &= ConsoleRead()

       If @error Then ExitLoop
       Sleep(25)
 WEnd

At present... I am writing $sOutput to a file (tif.ps) 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\tif.ps","", @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?

[Trong]

Try:

;~ 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\tif.ps', '', @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\tif.ps', '', @SW_MAXIMIZE, 8)
ProcessWaitClose($iPID)
$sOutput = StdoutRead($iPID)
MsgBox(32, "Output", $sOutput)

 

Edited May 11, 2016 by Trong
I think I do not know what you mean!

[JeremyNicoll]

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?

[ccbamatx]

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.

[JeremyNicoll]

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 May 11, 2016 by JeremyNicoll

[ccbamatx]

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.

[JeremyNicoll]

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 tif.ps    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.

[ccbamatx]

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 May 11, 2016 by ccbamatx
More Detail

[JeremyNicoll]

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.