Exec binding and echo, netcat, a pipe, carriage return and quotation marks

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/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 :smirk: )

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! :slight_smile: 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?