Create and run a batch via cmd vs direct execution

Does anybody know what is the advantage of executing a batch file via SHELL(cmd.exe ‘/c file.bat); instead of simply SHELL(file.bat)? If you know the answer straight forward you can stop reading now , otherwise below is a little background for my question: What I currently need is to run an external program, where the external progam is specified in setup Both in Std Navision and posted several times in this forum I’ve seen examples of creating a batch file and the executing that Batch file via cmd.exe The structure I’ve use so far to solve my task is taken from EFT File Transmiting in the North American version of EFT (COD10090/10091) Function TransmitExportedFile. However, since I need to run this in a Citrix Environnment I can’t create the batch file in the in client installation directory with [file.CREATE(FileName.Bat)] since there is no access to othe installation folder unless you are a Server Admin. Adding a valid path to filename creates the Batch file where I want it…but that gives me a problem when I try to excecute via CommandProcessor := ENVIRON(‘COMSPEC’); IF SHELL(CommandProcessor,’/c’,drive:Path\FileName) = 0 THEN ; since the Shell opens in the same installation folder as above and can’t find the batch file where I put it, even though the path is specified. I don’t get an errormessage, but I can tell the Batch File is not run. Calling the batch directly in the shell instead of via cmd.exe seems to work, but an itch in my left knee tells me that there must be a reason why the less straight forward cmd.exe approach is usually used. Thanks Jens

It is an odd thing. I know that in earlier versions of Navision there were a lot of problems with this, and if fact I thought it didnt even work as a direct command. Is it possible that this is something that changed in later versions, but that just due to “history” we still do it the old way?

quote:

Does anybody know what is the advantage of executing a batch file via SHELL(cmd.exe '/c file.bat); instead of simply SHELL(file.bat)?

There’s no reason to use the cmd.exe /c option when calling a .bat-file (or any other programfile for that matter). This option is primarily (if not solely) used for doscommands i.e. SHELL(‘CMD.EXE’, ‘/C’, DIR) - this opens a new instance of the command interpreter, carries out the command and then terminates. If you use /K instead of /C the command window remains.

Yes Steffan, I think its one of those “left over things” I know that I had an interface developed once, that required Navision to pull import files off a Unix system, and file.OPEN kept getting file locked errors (not very often, maybe 2-3 times a week), so I eventually used a batch to copy the files to a local FATdrive first. This was very unstable if I just called the bat directly, but adding the cmd /c it worked fine, running every 60 seconds 24/7. I for one just got then into the habit of doing it that way. Unfortuunaltely old habits die hard.

My knee is less itchy now so I’ll carry on with calling the Batchfile directly with the SHELL(); Thanks a lot for the input, most appreciated.

Just an additional one: It is easier to call the batch file using Windows Scripting Host than doing it from the SHELL command in Navision as (at least since 4.0) the system asks for confirmation for running the SHELL command at least once per machine. I’m not quite sure how it behaves on CITRIX and where Navision stores the answer to the CONFIRM for running the SHELL command.