# OH3 Windows 10 executeCommandLine can't run batch files

Is there a reason OH 3 (Windows 10 3.1.0M1) executeCommandLine in a script will not run a batch file? Doesn’t matter where the file is. It will not run any batch file anywhere. I can run anything else just fine, but not a batch file. It immediately returns null.

Other things like dir also don’t work. But for example ipconfig works fine.

Anything that doesn’t work from the script works perfectly fine from the command line.

I have tried everything and I’m losing my mind.

what does that exaclty mean ? Did you also put the batch file into a path that is known to the system like where the ipconfig command is located in ?
You may need to escape \ in paths like

c:\ => c:\\


Do you use arguments for your batch file ? How does your executeCommandLine look like ?
Is there any error mesage in openhab.log file ?
Does it help to start the batch file in a separate ‘shell’ ?
executeCommandLine( "cmd","/c","c:\\path\\to\\your\batchfile")
you may need to add time to wait for the command to finish

MyReturnValue=executeCommandLine( Duration.ofSeconds(timeout),"cmd","/c","c:\\path\\to\\your\\batchfile")

1 Like

For commands that don’t work, there is no error. It just instantly returns null and does nothing.

Using the full path to the file:
var response = exec.executeCommandLine(Duration.ofSeconds(10),"c:\\openhab\\conf\\html\\camDayNight\\camDay.bat");

Not using the full path to the file, since that full directory is in the windows path environmental variable.
exec.executeCommandLine(Duration.ofSeconds(10),"camDay.bat");

Forcing another shell I also already tried.
exec.executeCommandLine(Duration.ofSeconds(10),"cmd.exe", "/c", "c:\\openhab\\conf\\html\\camDayNight\\camDay.bat");

Any of the above methods work with some commands and not with others. Like for example, exec.executeCommandLine(Duration.ofSeconds(10),"ipconfig"); works perfectly. But exec.executeCommandLine(Duration.ofSeconds(10),"dir"); does not.

I even tried putting the batch files in the windows/system32 directory to see if that would make it happy and it does not.

There is no ‘dir’ command as a program file. That’s to say, you are not typing in a dos command line here. This would need to be a cmd /c dir type of thing, to invoke DOS before using DOS command.

Are you running openHAB as a service? This seems to make a difference here.

@rossko57 : what do you mean exactly by “are you running openHAB as a service? this seems to make a difference here”

Indeed, on my side, I’m struggling to find my issue, since executeCommandLine works fine in my rules if I start OpenHAB 3.1.0-M1 with .bat file, but not when I start it as a service: see here

Does it means I have to write it differently when OH3 is started as a service?

Here is the call in my rules so far:
val resp = executeCommandLine(Duration.ofSeconds(10), "C:/Users/SEBASTIEN/AppData/Local/Microsoft/WindowsApps/python.exe", "c:/OpenHAB3/conf/scripts/shaddow.py", "update")

Thanks for any help

As you found, it makes a difference. That’s the extent of my knowledge.

Doubt it, this must be about Windows user permissions and/or ability to run in foreground.

Related -

What I don’t really get is that it was working perfectly with no difference when using OH 2.5, and no longer with OH3.

One big difference is the java version (8 for OH2.5, while 11 for OH3), and considering it’s the same Win 10 on my side (no new Win installation, no change except last 1909 big update on WIN10), I would rather think it’s related to JAVA or the wrapper config and not windows permission itself.

Will dig more.

I am running OH as a service an still have these problems.

I have Similar problem trying to run a batch via exec binding- no sucess.

I think its related to the issue of OH as service in windows cant show a UI.

Reference here

for the exec binding compared to executeCommandLine on top you need to make sure that the executable is on the whitelist.

that is correct. In the other example python is mentioned; it is possible to create/use UI with python but at a starting point I would not expect that the other user programmed a UI in his python script.