LabVIEW
System Exec as blocking until cmd complete
Check the Standard output of System Exec. I'd wager you didn't connect Working directory and didn't manage to start the .exe correctly.
It should do as you describe and wait until the program is done, this can be easily tested in a simple VI like this snippet.
/Y
The purpose of the working directory still isn't clear to me.
I can launch a basic Windows app like notepad or calc and System Exec is blocking as @Yamaeda describes. Perhaps it has to do with the program I'm executing. Here is a sample program run from the command window:
I'm connecting to a remote client with putty. It prints "blah", then the date, prints back an argument (in this case "yoyo" is the argument), and finally it waits 10 seconds before printing "blah" again and returning. This works fine from the command window, but I can't get it to work from LabView with SysExec.
I've tried putting the command in a .bat file but Sys Exec returns as soon as the .bat file lists the command. It doesn't wait until the program is complete and doesn't print anything to standard output except the contents of the .bat file. I tried adding "start "" /B /WAIT" - again works from the command window but not from Sys Exec.
Has anyone addressed the issue that you need to use cmd /c to run directly from the prompt?
@wrkcrw00 wrote:
The purpose of the working directory still isn't clear to me.
Every process has a process global variable called "current working directory" CWD, that is used when you pass relative names to various file functions to resolve them in relation to this current working directory.
When using System Exec, the process is started as so called child process of LabVIEW, which means that it inherits various settings such as the environment variables, standard IO handles (which LabVIEW as a GUI process doesn't really have) and the CWD.
When you start a process from the Windows Shell (Explorer, batch file, etc) Windows usually sets the CWD to the same directory as where the actual executable is located. LabVIEW doesn't explicitly do so but gives you the option to set the CWD through that parameter. The CWD from LabVIEW can be not relied upon, since LabVIEW itself doesn't really use it but the Windows file dialog always changes this to whatever directory you are in when dismissing that dialog with the OK button. So when you select a VI to open it, you have implicitly changed the CWD of LabVIEW to the directory in which that VI is located.
For your purpose the CWD is probably not very important.
As to your problem itself, please post your VI. It's very hard to diagnose such issues with just some description of the problem, as it is very easy to misunderstand something, either by you describing what you see, or by us trying to reproduce it.
For instance your example about using "start "" /B /WAIT" is not going to work if you enter it like that as command to Sustem Exec.
start is a built in command of the cmd.exe. Windows itself doesn't know a command "start". The biggest problem is that people think that the System Exec command line is the same as what one would enter in the cmd.exe console. That is not the case. cmd.exe is a command interpreter that tries to interprete a pretty large number of commands directly and if it can't make sense of the command, it will pass it to the OS to let it try to resolve it. The System Exec in LabVIEW is only this last part without any kind of command interpreter in between. If the command in the command line to System Exec can't be resolved to an executable on disk by the Windows kernel, it will simply fail.
In order to get a cmd.exe like execution you have to prepend your command with cmd /c which will start the cmd.exe program and hand it the rest of the command line to execute. But there are difficulties: Everything you want cmd.exe to execute has to be passed through this single command line. You can't interactively add more commands to the sequence later on, like you can do in the cmd.exe window.
There are ways to get a more interactive execution by using pipes but System Exec doesn't support that. I've made in the past a library that tries to achieve this. It works for me for the things I needed, but pipes on Windows have some specific behavior that make it not as easy to use them. You need to be very careful about how fast you try to read from the pipes and be prepared that you can get timeout errors on the read operation and deal with them in most cases as non catastrophic error. It has been my plan to improve this part of the library to make it work more like the TCP Read function in LabVIEW, but that has never materialized so far.
This seems to work for me: 'cmd /c "C:\Program Files (x86)\PuTTY\plink.exe" localhost quicktest.sh yoyo'
And yes, i needed to set PWD to "C:\Program Files (x86)\PuTTY\"
/Y
@Yamaeda wrote:
This seems to work for me: 'cmd /c "C:\Program Files (x86)\PuTTY\plink.exe" localhost quicktest.sh yoyo'
And yes, i needed to set PWD to "C:\Program Files (x86)\PuTTY\"
That's because quicktest.sh is a relative path! Putty/plink will try to open it just like that but the according fopen() (or similar) C runtime function that plink calls to do that, will attempt to resolve this relative path using the Current Working Directory.
If you pass the full path to the shell script in the command line, the actual CWD may not be relevant anymore. I say may, because plink may rely on other files it tries to open with a relative path internally, such as configuration files, so it's not guaranteed that it will work with an arbitrary CWD.
