Ghostscript Command Not Working via System Exec.vi

[zou]

Try the "Start /wait" command in the batch file.

[maxnoder1995]

How will this affect LV data flow?

[zou]

---

@maxnoder1995 wrote:

I’m trying to run a Ghostscript command through LabVIEW's System Exec.vi, but it's not working as expected. The following command works fine in the command prompt:

gswin64c -dNOPAUSE -dBATCH -sDEVICE=png16m -r300 -sOutputFile="C:\Users\USERPROFILE\Desktop\SavePicturesFolder\%d.png" "C:\Users\USERPROFILE\Desktop\example.pdf"

However, when I use System Exec.vi in LabVIEW and pass the same string, it doesn't execute properly. 

---

 Please provide more detail for "doesn't execute properly".

[billko]

I believe whoever it was that suggested "cmd /c" is spot-on.  Try this, see if it works.

[Bob_Schor]

From the System Exec Help:

command line indicates the command LabVIEW calls to run a program. If the executable is not in a directory listed in the PATH environment variable, the command line must contain the full path to the executable. (Windows) To use a command that must be executed directly from a command prompt window, insert cmd /c before the command.

Do you normally execute Ghostscript from a Command prompt?  Then you need "cmd /c", it seems ...

Bob Schor

[rolfk]

---

@Bob_Schor wrote:

From the System Exec Help:

command line indicates the command LabVIEW calls to run a program. If the executable is not in a directory listed in the PATH environment variable, the command line must contain the full path to the executable. (Windows) To use a command that must be executed directly from a command prompt window, insert cmd /c before the command.

Do you normally execute Ghostscript from a Command prompt?  Then you need "cmd /c", it seems ...

---

It's slightly more complicated than this. What the help refers to are internal commands of the cmd.exe application, such as dir, del, copy and similar: https://www.lifewire.com/list-of-command-prompt-commands-4092302

These are implemented by cmd.exe itself and only can be called in the context of cmd.exe. For System Exec it means that you must invoke cmd.exe as primary program and then pass these commands as extra command line parameters to it.

Then there are external commands that are really executables on the system. These can be executed themselves but there are many possible gotchas here. The first one is that the CreateProcess() API used underneath, only will use the current path for completion of incomplete paths. So it will only find a program relative to that directory if the path is not an absolute path. But the current path is one of the most unreliable locations in a Windows GUI program that you can think of. It is usually initialized to the startup directory of the executable, except it that was started from another program, which means the current directory of the launching app will be inherited. To make matter really interesting, an application can change the current directory at any point by calling a Windows API. And to put the cherry on the top, the Windows file dialog will always change it to whatever directory it was in when dismissing the dialog affirmatively.

So this is usually very unreliable if you do not pass in the entire path to the relevant executable. Or you can invoke cmd.exe anyhow. cmd.exe will try to locate an incomplete executable name in the Windows directory, the System directory and any directory listed in the PATH environment variable. This covers pretty much any command line executable and potentially even other programs.

[Bob_Schor]

Thanks, Rolf.  I must admit that it did look "too easy to be true".  

BS

[billko]

---

@Bob_Schor wrote:

Thanks, Rolf.  I must admit that it did look "too easy to be true".  

BS

---

It's generally very good advice.  It's always worked for me.

[Yamaeda]

As mentioned CMD /c solves many issues, the rest are solved by setting the Working Directory input and/or using a batch file.