RE: LabVIEW SSH Tools

[Jim K. <ji...@ji...>]

Hi Rolf,

>=20
>=20
> Hi Jim
> =20
> > I haven't done any works with pipes in Windows and did a=20
> > little bit of research.  I found the following on MSDN:
> >=20
> >=20
> > =
<http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dllp
> > =
roc/base/creating_a_child_process_with_redirected_input_and_output.asp
> >=20
>=20
> >Has anyone gotten pipes working in LabVIEW?  Would anyone more C++=20
> >savvy than myself be interested in working with me to get a generic=20
> >"System Exec w/ Pipes" working?  I envision a DLL that could=20
> >be called=20
> >from LabVIEW (or maybe LabVIEW could call WinAPI DLLs directly) with=20
> >functions for Spawning the Process (the command-line executable),=20
> >Reading from, and Writing to a Pipe for communication with=20
> the running=20
> >executable.
>=20
> I haven't done anything with pipes yet although it isn't=20
> really difficult. The article you qoute seems fairly straight=20
> forward. I think the current System Exec most probably uses=20
> pipes for the three standard IO handles to get the StdIn/Out=20
> and Err at all. What is the problem is that you do not get=20
> the handle back but just the entire text after execution of=20
> the command.

You are right, I think.  In fact, if you look at the "Pipes" function
palette VIs in LabVIEW for Unix/Linux, "Open System Command Pipe.vi" =
does
just that (asynchronous system exec call with pipe outputs for
Read/Write/Error).  I have attached an example which uses this method to
call plink (also included in the attachment).  I have tgz'ed (rather =
than
zip'ed) the archive to preserve the Unix file system executable bit of =
the
plink file.  I have also attached a screenshot (pipe2plink.png) of the
example code for those out there without LabVIEW for Unix/Linux (and the
needed "Pipes" VIs).  This is a simple terminal-like GUI App that allows =
you
to execute single link commands via the secure shell and displays the =
I/O in
a buffered string indicator.

>=20
> I think although it might be sort of possible to go directly=20
> from LabVIEW to the Win32 API, it is a much better and=20
> smarter aproach to pack everything into a DLL. Instead of=20
> returning the entire StdOut/Err text at once it would return=20
> the three handles which can then be used by other DLL=20
> functions to read and write to/from those handles.
>=20

Yes, I think so too.  I was noticing that the WinAPI functions use some
compund (struct) data structures that might be hard to pass into a CLF =
node
from LabVIEW.

> The code as shown in above example would almost work for that=20
> already. At the moment I'm busy getting the Generic PortIO=20
> device driver working (Well generic in that it supports Port=20
> IO in direct fast and indirect slow mode (the one the current=20
> LabVIEW PortIO functions support) and possibly low mem=20
> access, not multiplattform although I got a Linux example=20
> too, just need to adapt it a bit to get it working nicely=20
> with LabVIEW.) I hope I have it ready end of this week and=20
> then I'll look into the inherited pipe system exec if nobody=20
> else stepped up to it until then.
>=20
> Rolf Kalbermatter
>=20

OK, thanks.  I've also pinged a TortoiseCVS developer (who is also an =
OpenG
Developer ;-) about this.  I'm hoping to hear back soon.

-Jim