Direct CMD Console In/Output

[chackl]

Hello!

Is there any possibility to read the output of a console / cmd command direkt to FS?`
I tried several things in ruby to read from the console and also had a workaround by using files by using "Commad >> file.txt"

So is there any direkt way to do this?

Thanks C.Hackl

[trogluddite]

So long as the command sends its output to its STDOUT (e.g. piping to a file is possible), you can collect the result using Ruby's "backtick" or "%x" notation. In this case, the command must execute and exit before you can collect the result, so you have to be careful that the command doesn't take too long, otherwise it might trigger the Ruby time-out.

This would look something like this...

Code: Select all

# Using backticks to delimit the command string...
result = `command -switch1 -switch2 ...  parameter1 parameter2 ...`

# OR, using the %x notation...
result = %x{command -switch1 -switch2 ... parameter1 parameter2 ...}

# Check that the command executed successfully.
if $?.success?
  # do something with the result.
end


Note...
- When you use the %x notation, you can use any type of bracket pair, or any other single character, as the delimiter.
- $? is a global variable which will contain a Process::Status object for the most recent command, from which you can determine whether the command executed successfully, its exit code, etc.
- You can insert variable values into the command string by using Ruby's usual #{...} string interpolation. e.g...

Code: Select all

result = `command #{@my_variable}`

If the command is something which needs to stay running rather than a "single-shot" command, then things get more complex, as there's not a simple way that I know of to synchronise collecting the output with the event-driven system of FlowStone Ruby. Using a pipe to a file, and then polling the file from FS, is probably going to be the easiest way. In this case, you need to launch the command differently so that Ruby doesn't wait for the command to exit...

Code: Select all

# Launch the command and read its process ID...
pid = spawn("command -switch1 -switch2 ... parameter1 parameter2 ... >> file.txt")
# Set the command free to run independently
# (NB: Capital 'P' for 'Process' - it's a module, not a method.)
Process.detach(pid)


If you have plenty of memory, the file stays small, and you delete it when you're done, it will likely remain in virtual page file memory rather than being written to disk - so using a file in this way isn't always as inefficient as it might appear.

[chackl]

Hi trogluddite!
Nice to see you still active

Well i did serveral checkups today - also with the three methods you mentioned above

BUT:
In any case i do not get any result in FS 3.0.8.1 (Also tried with the alfa x64)

I made a scematic to show - maybe there is something quite that simple that i may had missed?

Thank you!

[trogluddite]

Nice to see you around, too!

Hmm, same in FS 3.0.6. I wonder if this is a case of FlowStone Ruby being limited somehow. Your commands work fine when I execute them from a stand-alone Ruby script (I use command line a lot when Ruby scripting, so I took for granted that it would be just the same in FlowStone when I posted - d'oh!) It could be that the IO class that's used to implement STDIN/STDOUT/pipes has been messed with, in the same way that we don't have access to some of the threading methods (might make sense, as the standard Kernel I/O methods like puts and gets have no meaning in FlowStone.)

I think MyCo would be the person to ask about this - he should have some idea of how the FlowStone Ruby interpreter differs from the standard one.

[chackl]

Yes this makes sence.

Just like starting up a Flowstone-EXE with commandline parametes does also not bring you the parametes in ruby (In my tests)

I realy tried to use a lot of other functions eaven using windows named pipes. But at the first tries i was not able to get this done.

Last chance would be a custom DLL... (But this solution may be a little too advanced to my c++ knowlage)

Tanks you for your efforts

[tulamide]

Maybe it's not what you're looking for, but if I use $? after executing ping, $? tells me "pid <some id number> exit 0".

As far as I know, ping returns with either 0 (no error) or 1 (couldn't reach destination).

"$?" is a global that represents the process status of the last sub process executed.

If you are not interested in specific exit codes, you can also use system(), for example system("ping 8.8.8.8"). It will return either true (no error) or false (error).

But again, this might be known to you and is not what you're looking for?

EDIT: Oh, you probably mean the shell command output, like the string of the returned packets from ping?

[trogluddite]

^ Yes, I just checked $?.success?, and that returns true, too. These seem to confirm that it's something to do with the IO pipes - the command is executing successfully and returning a correct exit value, but the stream from the command's STDOUT is behaving as if piped to null.

That being the case, piping to a file and then reading the file once the method returns is probably the cleanest workaround. The following version of chackl's code seems to work fine in FS 3.0.6...

Code: Select all

temp_file = File.join(ENV['TEMP'], 'FS_RubyEdit_CommandLine.txt')

if system("ping 8.8.8.8 >> \"#{temp_file}\"")
  output File.read(temp_file)
  File.delete(temp_file)
end

[tulamide]

The following version of chackl's code seems to work fine in FS 3.0.6...

Code: Select all

temp_file = File.join(ENV['TEMP'], 'FS_RubyEdit_CommandLine.txt')

if system("ping 8.8.8.8 >> \"#{temp_file}\"")
  output File.read(temp_file)
  File.delete(temp_file)
end

Confirmed (well, half-confirmed), as it is running well in FS 4 64-bit as well. It may depend on the actual use case, but in terms of speed it isn't bad at all, and creating/deleting (often buffered) files on a modern harddisc shouldn't be too demanding as well. Awesome!

[chackl]

I just tested making a DLL that is grabbing the CMD output.
* seems to work
* seems to be as fast as using a file
* seems sometimes a little unstable
* not for FSx64...

Example in ZIP File. It was quite a ... because of charset-encoding and the windows cmd - because they use a locale-setting that may be different in germany / austria.

Regards.