Here’s something fantastic, for all those interested.
With PHP, you can simply execute command line commands by shell_exec, exec and so forth. You prepare your command, you tell it what to execute, and .. it gets executed, output is returned. If you want a more controlling interest in the application, you connect to stdin / stdout, and you have a communications path with the underlying system.
With ASP, on the other hand, things become a lot more interesting, and well, not as simple.
Let’s say you have a command line application, that takes commands, and starts, and might ask questions, or require input (or text stream) prior to terminating, and returning data.
How would you go about getting access to that data, and returning its result? Obviously, you could write it to file, but the web process can’t write to folders / files by default, and you might not want write permissions on a folder needlessly.
So, the solution is bought to you by Microsoft.
You need to know the location of the executable, and any parameters it takes, and do the following. The same applies for using it as a WSH (windows scripting host) script as well.
PathToApp = “C:\progra~1\app\app.exe”
AppArgs = “-v –help”
Set sh = Server.CreateObject(“WScript.Shell”)
Set exec = sh.Exec(PathToApp & ” ” & AppArgs)
exec.stdin.writeline(“The data stream I need is right here. The data is going to be used to net send another server.”)
exec.stdin.writeline(chr(26)) ‘ chr(26) is the EOF character, your program might require EOF to finish waiting on data.
exec.stdin.close ‘ this closes the StdIn stream, a program might also wait on this instead
‘ The above deals with getting the application started, and feeding it data. We still wanna see what it thought of it.
While Not exec.StdOut.AtEndOfStream
Response.Write “Line: ” & exec.StdOut.ReadLine() & “
While Not exec.StdErr.AtEndOfStream
Response.Write “Error: ” & exec.StdErr.ReadLine() & “
Set exec = nothing
set sh = nothing
Basically, what the StdErr stream contains is any messages of an error in nature, some applications use StdErr instead to communicate, so it keeps any messages that might be informational in nature away from the output, which might be required to be intact for further processing.
So, stderr might contain messages of a status in nature, like “Finished” for example. This is a great method for communicating with command line applications though, because it keeps you secured to your own spawned wscript object, and if you don’t have any bugs, or spawn any windows, you can go undetected, aside from task manager and the pslist, obviously not the intention here though.
If you compare this method with echoing information on the command line, you can realise that the command line on linux (not this jobs purpose) can be read by anyone, for example, cat /proc/process-num/cmdline could reveal information you might not want revealed. And of course, writing information to files in any environment carries the risk that it might be read by someone else as well, even if temporarily. Disk drives can be recovered.
NB: You use any information contained on this website at your own risk. It’s not my problem if you use it incorrectly. All information provided on an all care, but no responsibility basis.