I have a fairly lengthy command-line program that requires user input of parameters and then processes using those parameters. What I would like to do is split the program into interactive and non-interactive. I attempted to do that, and intended to have the non-interactive program "call" the interactive program and using the results (parameters), process based on those parameters. The non-interactive part of the program displays results on the console as it processes. I have looked at Process.run and Process.start, but apparently they don't function that way. There is another similar question to this that is about 12-months old, so I thought it worthwhile asking again.
I have looked at Process.run and Process.start, but apparently they don't function that way.
Process.start is what you want here. It can do what you want, but you'll have to become a bit more comfortable with async programming if you aren't already. You'll spawn the process and then asynchronously read and write to the spawned processes stdout and stdin streams.
Your interactive program can do something like this:
// interactive.dart
import 'dart:io';
main() {
var input = stdin.readLineSync();
print(input.toUpperCase());
}
It's using stdin to read input from the command line. Then it outputs the processed result using regular print().
The non-interactive script can spawn and drive that using something like:
import 'dart:convert';
import 'dart:io';
main() {
Process.start("dart", ["interactive.dart"]).then((process) {
process.stdin.writeln("this is the input");
UTF8.decoder.fuse(new LineSplitter()).bind(process.stdout).listen((line) {
print(line);
});
});
}
It uses Process.start to spawn the interactive script. It writes to it using process.stdin. To read the resulting output it has to jump through some hoops to convert the raw byte output to strings for each line, but this is the basic idea.
Related
For example, here is a simple dart code:
#import('dart:io');
main() {
var server = new HttpServer();
server.listen('127.0.0.1', 8080);
server.defaultRequestHandler = (HttpRequest request, HttpResponse response) {
response.outputStream.write('Hello, world'.charCodes());
response.outputStream.close();
};
}
when the web server print the 'Hello, world', I would like to run a progress to run a
long heavy task, but don't want to it blocking the current process. May I know how to handle it? Thanks.
I tried with Process.run and Process.start with no success.
From you comment I can tell there are a misunderstanding of how Dart works spawning external processes. When you spawn a process in Dart it is by default running so the Dart program and the external program are running separate (so in different processes) and the Dart program can execute other stuff. You can then await for the result from the program (e.g. when it closes).
Therefore it does not make much sense to run the process with "&" as parameter (I guess this was an attempt to tell it should run separately from the Dart program).
But, since you are spawning another Dart program your should also consider using an Isolate which can execute both your own method on another thread or run external code by using:
https://api.dart.dev/stable/2.6.0/dart-isolate/Isolate/spawnUri.html
I need to write QuizApp using Dart Command-Line Apps. There is a some example from Dartlang.org but all of the related 2013 which is very old. I am using Dart 2 and I need to write a quiz app.
I need to know how to use stdin, stdout, listen and subscription so the app doesn't quit after 1 enter.
How to write QuizApp using Dart Command-Line Apps
You don't really need any use of subscription for a simple quiz command-line application. You only need to use stdin and stdout from the dart:io package since the application does wait for input when you are using 'stdin.readLineSync()'.
I don't want to make you homework so I am only going to give a small example:
import 'dart:io';
main() {
while(true) {
stdout.writeln('Are you OK? (Yes/No)');
if (stdin.readLineSync().toLowerCase() == 'yes') {
stdout.writeln('Then stop trouble me!');
return;
} else {
stdout.write('Let me ask again! ');
}
}
}
This is probably not of major importance, however I have noticed during testing that the performance of the print statement and also stdout is much faster in the Dart-Editor than from the command-line. From the command-line the performance of print takes around 36% longer than using stdout from the command-line. However, running the program from within the editor, using stdout takes around 900% longer than using the print statement in the editor, but both are considerably faster than from the command-line. ie. Print from a program running in the editor takes around 2.65% of the time it takes from the command-line.
Some relative timings based on average performance from my test :
Running program from command line (5000 iterations) :
print 1700 milliseconds.
stdout 1245 milliseconds.
Running program within Dart-Editor (5000 iterations) :
print 45 milliseconds
stdout 447 milliseconds.
Can someone explain to me the reason for these differences – in particular why performance in the Dart-Editor is so much faster? Also, is it acceptable practice to use stdout and what are the pros and cons versus using print?
Why is the Dart Editor faster?
Because the output handling by the command line is just really slow, and this blocks the output stream, and subsequently the call to print/stdout.
You can test this for yourself - test the following java program (with your own paths, of course):
public static void main(String[] args) {
try {
// the dart file does print and stdout in a loop
Process p = Runtime.getRuntime().exec("C:\\eclipse\\dart-sdk\\bin\\dart.exe D:\\DEVELOP\\Dart\\Console_Playground\\bin\\console_playground.dart");
BufferedReader in = new BufferedReader(new InputStreamReader(p.getInputStream()));
StringBuffer buf = new StringBuffer();
String line;
while((line = in.readLine()) != null) {
buf.append(line + "\r\n");
}
System.out.print(buf.toString());
} catch (IOException e) {
e.printStackTrace();
}
}
On my machine, this is even slightly faster than the Dart Editor (which probably does something like buffering the input and rendering it periodically, but I don't really know).
You will also see that adding a Thread.sleep(1); into the loop will severely impact the performance of the dart program, because the stream is blocked.
Should stdout be used?
I think that's highly subjective. I, for one, do whatever lets me write code more quickly. When i just want to dump a variable, i use print(myvar);. But with stdout, you can do neat stuff like this: stdout.addStream(new File(r"D:\test.csv").openRead());. Of course, if performance is an issue, it depends on how your application will be used - for example, called by another program (where print is faster) vs. command line (where stdout is faster, for some reason).
Why is stdout faster in command line?
I have no idea, sorry. It's the only environment I tested where print() is slower, so I'd guess it has something to do with how the console handles incoming data.
I want to execute a python or a java class from inside dart.
The following is a snippet which I have used from a stackoverflow question Java
Runtime currentRuntime = Runtime.getRuntime();
Process executeProcess = currentRuntime.exec("cmd /c c:\\somepath\\pythonprogram.py");
I would like to know how to make such calls in dart.
Basically I have a UI where in the user uploads code in java and python.I want to execute the uploaded code from the dart environment instead of creating a routine in java or python on the folder where the code is uploaded.
I personally dont know if this is possible, since dart is purely in a VM.
I want to execute the following command
java abc
from inside dart.
You can simply use Process.run.
import 'dart:io';
main() {
Process.run('java', ['abd']);
}
You can also access to stdout, stderr and exitCode through the resulting ProcessResult :
import 'dart:io';
main() {
Process.run('java', ['abd']).then((ProcessResult pr){
print(pr.exitCode);
print(pr.stdout);
print(pr.stderr);
});
}
I wrote the following two functions, and call the second ("callAndWait") from JavaScript running inside Windows Script Host. My overall intent is to call one command line program from another. That is, I'm running the initial scripting using cscript, and then trying to run something else (Ant) from that script.
function readAllFromAny(oExec)
{
if (!oExec.StdOut.AtEndOfStream)
return oExec.StdOut.ReadLine();
if (!oExec.StdErr.AtEndOfStream)
return "STDERR: " + oExec.StdErr.ReadLine();
return -1;
}
// Execute a command line function....
function callAndWait(execStr) {
var oExec = WshShell.Exec(execStr);
while (oExec.Status == 0)
{
WScript.Sleep(100);
var output;
while ( (output = readAllFromAny(oExec)) != -1) {
WScript.StdOut.WriteLine(output);
}
}
}
Unfortunately, when I run my program, I don't get immediate feedback about what the called program is doing. Instead, the output seems to come in fits and starts, sometimes waiting until the original program has finished, and sometimes it appears to have deadlocked. What I really want to do is have the spawned process actually share the same StdOut as the calling process, but I don't see a way to do that. Just setting oExec.StdOut = WScript.StdOut doesn't work.
Is there an alternate way to spawn processes that will share the StdOut & StdErr of the launching process? I tried using "WshShell.Run(), but that gives me a "permission denied" error. That's problematic, because I don't want to have to tell my clients to change how their Windows environment is configured just to run my program.
What can I do?
You cannot read from StdErr and StdOut in the script engine in this way, as there is no non-blocking IO as Code Master Bob says. If the called process fills up the buffer (about 4KB) on StdErr while you are attempting to read from StdOut, or vice-versa, then you will deadlock/hang. You will starve while waiting for StdOut and it will block waiting for you to read from StdErr.
The practical solution is to redirect StdErr to StdOut like this:
sCommandLine = """c:\Path\To\prog.exe"" Argument1 argument2"
Dim oExec
Set oExec = WshShell.Exec("CMD /S /C "" " & sCommandLine & " 2>&1 """)
In other words, what gets passed to CreateProcess is this:
CMD /S /C " "c:\Path\To\prog.exe" Argument1 argument2 2>&1 "
This invokes CMD.EXE, which interprets the command line. /S /C invokes a special parsing rule so that the first and last quote are stripped off, and the remainder used as-is and executed by CMD.EXE. So CMD.EXE executes this:
"c:\Path\To\prog.exe" Argument1 argument2 2>&1
The incantation 2>&1 redirects prog.exe's StdErr to StdOut. CMD.EXE will propagate the exit code.
You can now succeed by reading from StdOut and ignoring StdErr.
The downside is that the StdErr and StdOut output get mixed together. As long as they are recognisable you can probably work with this.
Another technique which might help in this situation is to redirect the standard error stream of the command to accompany the standard output.
Do this by adding "%comspec% /c" to the front and "2>&1" to the end of the execStr string.
That is, change the command you run from:
zzz
to:
%comspec% /c zzz 2>&1
The "2>&1" is a redirect instruction which causes the StdErr output (file descriptor 2) to be written to the StdOut stream (file descriptor 1).
You need to include the "%comspec% /c" part because it is the command interpreter which understands about the command line redirect. See http://technet.microsoft.com/en-us/library/ee156605.aspx
Using "%comspec%" instead of "cmd" gives portability to a wider range of Windows versions.
If your command contains quoted string arguments, it may be tricky to get them right:
the specification for how cmd handles quotes after "/c" seems to be incomplete.
With this, your script needs only to read the StdOut stream, and will receive both standard output and standard error.
I used this with "net stop wuauserv", which writes to StdOut on success (if the service is running)
and StdErr on failure (if the service is already stopped).
First, your loop is broken in that it always tries to read from oExec.StdOut first. If there is no actual output then it will hang until there is. You wont see any StdErr output until StdOut.atEndOfStream becomes true (probably when the child terminates). Unfortunately, there is no concept of non-blocking I/O in the script engine. That means calling read and having it return immediately if there is no data in the buffer. Thus there is probably no way to get this loop to work as you want. Second, WShell.Run does not provide any properties or methods to access the standard I/O of the child process. It creates the child in a separate window, totally isolated from the parent except for the return code. However, if all you want is to be able to SEE the output from the child then this might be acceptable. You will also be able to interact with the child (input) but only through the new window (see SendKeys).
As for using ReadAll(), this would be even worse since it collects all the input from the stream before returning so you wouldn't see anything at all until the stream was closed. I have no idea why the example places the ReadAll in a loop which builds a string, a single if (!WScript.StdIn.AtEndOfStream) should be sufficient to avoid exceptions.
Another alternative might be to use the process creation methods in WMI. How standard I/O is handled is not clear and there doesn't appear to be any way to allocate specific streams as StdIn/Out/Err. The only hope would be that the child would inherit these from the parent but that's what you want, isn't it? (This comment based upon an idea and a little bit of research but no actual testing.)
Basically, the scripting system is not designed for complicated interprocess communication/synchronisation.
Note: Tests confirming the above were performed on Windows XP Sp2 using Script version 5.6. Reference to current (5.8) manuals suggests no change.
Yes, the Exec function seems to be broken when it comes to terminal output.
I have been using a similar function function ConsumeStd(e) {WScript.StdOut.Write(e.StdOut.ReadAll());WScript.StdErr.Write(e.StdErr.ReadAll());} that I call in a loop similar to yours. Not sure if checking for EOF and reading line by line is better or worse.
You might have hit the deadlock issue described on this Microsoft Support site.
One suggestion is to always read both from stdout and stderr.
You could change readAllFromAny to:
function readAllFromAny(oExec)
{
var output = "";
if (!oExec.StdOut.AtEndOfStream)
output = output + oExec.StdOut.ReadLine();
if (!oExec.StdErr.AtEndOfStream)
output = output + "STDERR: " + oExec.StdErr.ReadLine();
return output ? output : -1;
}