Wish I’d found this thread a week or two ago. The tip about @@ and spaces might have solved why I couldn’t get the exec binding working the way I first wanted.
In the end I simplified my problem to help track down the issue and get it working. All I was trying to do was extract the OH versIon number from the system so I could put the text on my sitemap (borrowed the idea from someone elses post). It’s a simple grep piped to awk with a print $2 nothing fancy or complicated.
But I couldn’t get exec to work. So I switched to the command line did more testing there and then stuck it in .sh script. Really wasn’t what I wanted for a one liner exec but going back in to OH I could then call the script and it worked. 
@nakh_Home I would recommend that if you can you use something like MQTT rather than the exec binding and rules.
I was initially reluctant to go that route myself but once I got fed up of the coupling and rules I was having to write I bit the bullet and deployed Mosquito on my server. In reality it was very easy, not much more required than apt-get install mosquito couple of config changes in Mosquito and OH and it was a beacon of information for events happening inside OH.
I think IanJ above also reached the point of pain trying to use exec binding to post state changes:
do you know of anything that can manage the proliferation of things/items/scripts/rules/sitemaps?
Now if I want to add a new switch I do the basics in OH to create the item and I don’t need any rule changes to publish its event changes. Just go to the client implementation I have that is interested in the new switch and add a new subscription to it’s list.
I haven’t used MQTT to update OH although I think you might be able to…? I found this Python module does what I need to send data back to OH.
It’s also a better pattern to reduce your coupling from server to clients. Over time I’ve found more and more reasons why I want another client doing ‘something’ and with this method and a simple Python script it’s easy. Plus MQTT and the Python module take care of the comms over TCP meaning if my client is on the same server or different my OH doesn’t care, no ssh key sharing.
@FrankR I would also consider changing your approach. Drop the use of exec binding and link up with MQTT and the OH Python module to push data back, I see you are already using py scripts. I do try and keep my clients as dumb as possible and put business logic in OH so if you want the data collection triggered by OH just create a switch item that your rpi client monitors via MQTT subscription, send back the data when requested and clear the switch.
Sorry this seems to have changed in to “don’t use exec binding” but that was not my purpose, indeed I think it’s exactly what I need for my OH version string. Just wanted share that simplifying your exec binding to external scripts is often a quicker way to get it working as @rlkoshak has suggested. But where possible also consider why you’re using it whether there is a different tool in the box that might be more appropriate.