oo of course. Stupid me.
Actually now that you type that I realize that the issue is when the slashās are combined with the -e flag and inside the quotes. Cause cd /mnt/media/Calibre\ Library/ is how you would move to the Calibre folder, or cd "mnt/media/Calibre Library/
Correct, both work so maybe the quotes make it so you donāt need the three spaces.
I tried this script:
#!/bin/sh
/bin/echo -e "$1 -\r"
which produced
POWR1 -
There are three spaces between POWR1 and the ā-ā. So that works. I also put stuff after the \r to see if that was working and it is.
Then I tried to pass in the three spaces with the carriage return as the argument and I see the same behavior (i.e. echo is concatenating the spaces.
Neither "POWR1 -\r" worked nor "POWR1\ \ \ -\r" nor POWR1\ \ \ -\r worked.
So the question becomes, is it only some of these commands that need the three spaces or all of them? If all of them then just use the first script. If only some of them you may need multiple scripts, one for the three spaces and one without.
Yes, that is what I was experiencing. Not entirely sure why, but escaping out spaces doesnāt work there. However the double quotes and three spaces INSIDE the script (with the correct backslash in front of the r) did seem to work. I believe most of the commands are only 5 digits (of the 8) and its no problem to create a second (or third) script this easy to account for the others. Thanks again for all your help.
Though, now knowing what I do about the possibility of multiple spaces being condensed into 1 and the ābreak it down into smaller partsā strategy you reminded me off, I think Iām going to go back and troubleshoot the rule/exec binding again. What can I say? Iām a gluttony for pain and frustration:)
So Iām officially quitting my attempts to get this work with the actual command in an exec binding item. Maybe one day, somebody will meander through here and explain to me why what is seemingly the right command being sent by the exec item, doesnāt work, but Iām not gonna hold my breath or waste any more time trying to figure it out now that the script is working.
I just have one question/clarification. I was putting my sharptv.sh file inside the {$openhabhome}/configurations/scripts folder as sharptv.sh. And it would work once I chmodāed it as executable, but the setpermissions script run at boot chmodās all the files back to UNexecutable. After reading the wiki on scripts Iām realizing that scripts in this folder are actually not supposed to be called INSIDE items (is that correct?) and that they should actually have the .script extension. So is the best option here to put the script inside of a non-openHAB owned folder so that it keeps the right permissions/executableness, or is there a better, more ācontainedā method for calling a script inside an item?
I have some more questions now that Iām over that hump, but Iāll start a new thread, for all intents and purposes, after I understand the answer to the above small question, this issue is essentially resolved (I guess 
)
So the scripts folder is supposed to be for OH scripts, not shell scripts. OH scripts are like standalone rules or parts of rules you can call from inside your rules, not your Items or from the exec binding. They have some severe limitations though and Iāve never found a use for them. And in fact I too put my shell scripts into this folder and when I call them from a Rule I chmod them before calling them in that rule. I will someday move these scripts somewhere else, perhaps ~openhab/bin or the like which is a more appropriate location.
As of OH 1.8.2 the files in ~openhab no longer have their permissions blindly reset.
which location are you referring to here? /etc/openhab/configurations? Iām running 1.8.2ā¦
On Linux and other Unix type operating systems, ~<username> is shorthand for that userās home directory. So if I have a login of rich I can either cd /home/rich or cd ~rich.
So ~openhab is the openhab userās home directory. If you didnāt create the openhab user yourself, by default apt-get puts ~openhab in /var/lib/openhab.
ah gotcha, Thanks! so youāre saying that putting a folder in ~openhab and calling it bin (or something) should shield it from the āon bootā setpermissions script?
It should. I submitted an issue which was implemented and released as part of 1.8.2.
cool thanks for the tip. One final question: can I use ${openhab_home} or some other variable as a reference to that home directory? I assume if itās allowed itās the same as whatever the variable is called in openhab.ini.shā¦
Only if that environment variable is set in the shell you are working from. It works in the start scripts because they explicitly read in a file that sets them.
You can see if that variable is set in your shell by typing echo $openhab_home. Iād be shocked if it is set.
Yup youāre right, Iāll use the full path. Now Iām working on your git suggestions! 
Do you just have the /etc/openhab/configurations folder as a git repository? I currently have all the various folders symlinked to a created share at /home/openhab, but I think iād run into issues, and at the very least, too much noise, if I make the whole created directory a repository.
edit: nvm i see earlier you say its just your /etc/openhab/ that you symlink to your home folder. I officially will not bother this thread any longer:slight_smile:
ok i lied. I realized there is sensitive information in openhab.cfg. I assume you donāt push that to github, anything else you add to .gitignore?