On Wednesday, 9 October 2013 at 14:27:30 UTC, Jesse Phillips
wrote:
On Wednesday, 9 October 2013 at 11:22:26 UTC, Colin Grogan
wrote:
"
~/test$ ./mess ls
Executing: ls
STDOUT: mess
STDOUT: text.txt
"
Thats all fine, however, I'd expect it to print another
"~/test$" at the end, as if its an interactive shell waiting
for input.
It is extracting the output of the program, 99.9% of the time
this is what everyone wants and including the shells behavior
would be terrible.
But its exactly what I want ;)
If you run bash, then it is going to be waiting for stdin so
you'd need to pass it "ls" and "exit" to get the output and
quit. I'm not sure this would get you want you wanted.
That would imply that the call to
pipeShell("/bin/bash", Redirect.all);
is blocking. However, its not meant to be blocking is it not?
That new /bin/bash process is meant to run in parallel to the
main process?
If I use the program to execute the following script:
#!/bin/bash
for i in {1..100}
do
for j in {1..100}
do
echo "$i, $j"
done
sleep 15
done
and monitor the output that is printed, I can see that it is
indeed sleeping for 15 seconds, so the pipeShell call is
definitely non-blocking.
I assumed it should behave the same way for /bin/bash. It is just
another process after all, surely pipeShell knows nothing more
about /bin/bash that it does about my silly script above?
