6 replies to this topic

[CraigGraham]

I need to launch and control an existing commandline app from Labview. By this I mean I need to be able to read it's STDOUT and send things to STDIN while it is actually running.

In .NET I can do it, and since we now have access to the .NET stuff it would seem I should be able to do it this way in Labview. However, although I can create and start the process, Labview doesn't seem to be able to handle the System.IO.StreamReader reference that comes back from the "StandardOutput", "StandardInput" and "StandardError" properties of the Process object. If I wire it straight to a property or invoke node, no name appears in the node and no properties or methods are available. In .NET I don't have to do anything special to this object- it just has properties and methods that let you see what's going on.

On Linux you can do similar using pipes, I gather. And there are pipes on WinXP, apparently, but the Labview docs say pipes are only supported in Unix versions of Labview.

So does anyone know how I can get the .NET stuff to work in Labview, or know an alternate way of doing this whilst remaining inside Labview?

[CraigGraham]

How bizarre. I gave up on this when I posted and closed Labview. On deciding to have another crack, I got the message the assembly "mscorlib" was missing and needed to be added to the list of private assemblies. Did so and I'm now getting somewhat further.

It's odd that it couldn't find it- nothing visibly abnormal. Labview 7 and Framework 1.1.

[Jim Kring]

Craig,

The developers at OpenG are working on a pipes package for Windows which will include an "Open System Command Pipe" VI. I am not sure when this will be finished, but I can tell you that we have some very talented folks working on it.

-Jim

[CraigGraham]

Ooo, such modesty there.

After all the messing, I have the interactive stuff working for commands like "ping". However, the one I'm trying to get control of is Gnu's PGP equivalent. Although it's a command line interface, catching its standard input, output and error streams do absolutely nothing. Evidently there are several ways of conversing via a text terminal and whatever GPG is using isn't well liked by .NET

So it's a case of sleeping on it and seeing if inspiration hits :/

[Jim Kring]

Craig,

Ooo, such modesty there.

Well, I wasn't referring to myself

After all the messing, I have the interactive stuff working for commands like "ping". However, the one I'm trying to get control of is Gnu's PGP equivalent. Although it's a command line interface, catching its standard input, output and error streams do absolutely nothing. Evidently there are several ways of conversing via a text terminal and whatever GPG is using isn't well liked by .NET

Calling SSH from a system command pipe, requires passing the -T option so that it does not generate a TTY terminal shell. I don't know if GPG has anything but you might want to take a look at all of its command-line arguments and see if anything looks similar.

So it's a case of sleeping on it and seeing if inspiration hits :/

Have you tried calling GPG from a system command pipe on Linux?

Cheers,

-Jim

[CraigGraham]

Ooo. There IS an option "--no-tty" that I thought just suppressed all output. It turns out it lets me redirect the streams to get at them from inside Labview, but when I try and do interactive stuff it tries to be too clever;

gpg: Sorry, no terminal at all requested - can't get input

So I think I'll call it quits for the moment. There's two alternatives- LibGCrypt on Linux that I'm going to play with, and the commercial PGP SDK that I'm looking into. Though I suspect the commercial one will be a bit too pricey and charged per deployment.

Can Labview on Linux use dynamic link libraries? Might be an option if we go the LibGCrypt route, but we don't yet have LV on Linux and they seem to have stopped the Linux evaluation CD that used to be available.

[Jim Kring]

Yes, LabVIEW can call shared libraries on Linux. They are called shared object files and usually (if not always) have a .so file extension.

A while ago, I looked at the possibility of a GPG toolkit for LabVIEW as a way of signing OpenG Package Files. Maybe this will happen some day...