command-line interaction

[David Moerman]

Hello,

I am using LabVIEW 6.1 for an application on linux. I wish to use the command line 'sftp' client to do secure ftp transfers. I've been investigating how to do this with LabVIEW and I've come up with the following solution that *almost* works.

I'm using a utility called "Expect" from expect.nist.gov, which is based on Tcl. I've created a script that works great when I execute it from my shell prompt. However, when I use the LabVIEW System Exec function, I can see the script executing, and then it simply stops when it attempts to spawn the sftp process.

I was wondering if anyone knows of a way around this. I'm also willing to consider alternate approaches to my problem of interacting with a command-line application.

Thanks,

David Moerman, Advanced Measurments Inc

[David Moerman]

Well, I got the "Expect" utility to work, mostly. I'm pretty happy about this, because now I can get LabVIEW to communicate with ANY interactive command-line client. If anyone else is interested in this, there is another good resource newsgroup at comp.lang.tcl.

Thanks anyway,
-Dave

[David Duffey]

Hi David,

I'm glad that you got expect working under LabVIEW 6.1

Under LabVIEW 7, you could also be use the "Open System Command Pipe" VI found in the Communications -> Pipes palette which would give file descriptors that you can read and write to with the pipe VIs.

This would give you a purely LabVIEW solution, but if you already have it working in expect, no sense in re-inventing the wheel.

Cheers,
Duffey

[David Moerman]

Thanks for your reply. Just out of interest though: I didn't bother pursuing command-line interaction with pipes because of a problem I ran into earlier when I tested this idea.

I tried using a pipe (with mkfifo) from the bash command line, to send input to a ftp process. It almost worked... but I found that the EOF resulting from an empty input pipe would cause the ftp client to quit (as stated in the man page). I could see no way around this since the ftp process would empty the pipe as fast as I could fill it.

So it would follow that if pipes don't work in bash (for this application) they won't work in LabVIEW either. Unless I'm missing something fundamental here...

Personally, I would rather do without "expect". The "Tcl" on which it's
based is rather bloated.

Regards,
-Dave

[David Duffey]

Ah, a weirdness with sftp. I ran a test like this on my machine:

# begin typing
mkfifo /tmp/test
ftp < /tmp/test
cat > /tmp/test
open ftp.ni.com
cd /incoming
ls
^D
# end typing ^D, is control, D of course

You should see the results as you type the commands to cat (cat keeps the pipe open, until ^D). You should be able to do something similar in LabVIEW with the pipe commands.

As long as you don't close the pipe, then ftp should stay running, even if there is nothing to read in the pipe. FTP shouldn't close the pipe, rather it should wait syncronously until there is something to read.

But when I tried it with sftp (from openssh), it would only work if it did not need to ask me for a password (either due to host based a
uthentication, or having already provided a passphrash). If it needed a password, before it would read from the pipe, it would undo the stdin I specified (with the pipe), and actually read the password from the interactive shell. After correctly entering the password (from the shell that executed sftp, not the pipe), it would continue as normal and accept commands from the pipe.

I hope some of this helps you in the future.

[David Moerman]

Thanks David.
These little tricks make a world of difference. I didn't think to keep the pipe open using cat. Of course, it makes complete sense that the EOF would terminate ftp because I was closing the fifo!

Anyway, this method has great promise. I would like to ditch expect as it takes up too much room on my flash-based drive. As for that password problem, I see the same problem when I tried it with plain ftp. But like you say, with sftp I should be in the clear if I provide my public key to my ftp host (this is a definite possibility with the system I'm developing).

Now I'm going to contradict my earlier statement. Unfortunately, although sftp is my inevitable goal I need to get plain ftp going in the short term, so the
password problem is still a problem. Another strange thing, the ftp client output (stdout?) does not appear (like the "200 Transfer complete" stuff). I also tried using the 2>&1 redirection with no luck. I'll keep playing and see what I can do.