OH3 migrated Rule executeCommandLine() command fails

I migrated my complete system from OH2 to OH3, including my .rules file. I changed my Rules code for executeCommandLine() from the old syntax to the new (see below); but the new syntax version fails. Any ideas?

// old rule line in OH2
var response = executeCommandLine(String.format("wget -N -P %s %s", cacheFolder, sourceIcon), 5000)

// changed rule line in OH3
var response = executeCommandLine(Duration.ofSeconds(5), String.format("wget -N -P %s %s", cacheFolder, sourceIcon))

In the latter version the variable response returns a null value…

Oh come on,you know we want to know “fails how?” :wink:

So far as I understand the syntax, you add space-separated parameters as, well, separate parameters.

executeCommandLine(Duration.ofSeconds(5), "wget", "-N", "-P", cacheFolder.toString, sourceIcon.toString)

You might need to do your formatting of variables individually before building the exec line.

Aha. I will try that, thank you. (The open ended String argument explains why the duration was shifted from being the second argument in OH2 to being the first argument in OH3…)

So I did. See the last line of my post. :slight_smile:

Thank you for your help. I made some progress. The wget command does now execute and the requested icon file is indeed downloaded. However in OH2 the result return value of executeCommandLine() was a String that contained the HTTP headers, whereas now there seems to be no return value??

=> So what is the return value type of executeCommandLine()? Is it now void? And if so, is this a bug / regression?

EDIT: I think this is indeed a bug / regression between OH2 and OH3

var response = executeCommandLine(Duration.ofSeconds(5), "wget", "-N", "-P", cacheFolder, sourceIcon)
// the icon file is fetched so response should contain the HTTP headers
logWarn("Rules", "HTTP GET Response: " + response)
// but actually response is an empty string value
2021-01-13 13:24:46.149 [WARN ] [org.openhab.core.model.script.Rules ] - HTTP GET Response: 

@rossko57 it gets mysteriouser and mysteriouser; try running the following rule; (on a Pi4 running OpenHabian)…

rule "ZZZ"
    Item AAA received update
  var response = executeCommandLine(Duration.ofSeconds(5), "ls");
  logWarn("Rules", "ls response: " + response)
  val sourceIcon  = "https://darksky.net/images/weather-icons/rain.png"
  val cacheFolder = "/etc/openhab/icons/classic/weather-icons/"
  response = executeCommandLine(Duration.ofSeconds(5), "wget", "-N", "-P", cacheFolder, sourceIcon)
  logWarn("Rules", "wget response: " + response)

And you get the following log outputs. As you can see, executeCommandLine() does return the console output from the ls command, but it does NOT return the console output from the wget command. This is different than in OH2 where the command returns the console output in both cases…

2021-01-13 16:00:26.642 [WARN ] [org.openhab.core.model.script.Rules ] - ls response: cache

2021-01-13 16:00:27.221 [WARN ] [org.openhab.core.model.script.Rules ] - wget response: 

EDIT: I just tried curl too; it works for ls but not for wget or curl – go figure…

I don’t have OH3 (or *nix host) to try it, but this is no doubt one of those things about the executed line is not running in a shell context.

I think it may be this ExecUtil.executeCommandLine() is broken · Issue #1677 · openhab/openhab-core · GitHub

Alright, that issue is closed so nothing further will happen there.
In your comment there, you suggest it’s about execution time? Do you just need a longer timeout?

EDIT - I’ve seen one user suggest that the timeout was not working for them. You are able to estimate that with the before and after timestamps on your logInfo()s.
It looks like your wget returned in about 500mS, which might be reasonable.
If you want to check this, use a nonsense URL to force a full timeout.

As far as I can see wget does not write something to STDOUT. I think that is the reason why no result is being returned.
The output that is written by wget is written to STDERR.
In case you change the wget command and add an arguments like: -O - then the downloaded icon will be written to STDOUT ( which does not make sense because it is binary data ) but you will see that this returned value can e.g. written to loginfo.


Many thanks @Wolfgang_S and @rossko57, for your info I opened a PR to fix this issue in the next release of OH…