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

One thing I’ve noticed over and over but haven’t commented on because I figured it was just a typo but to do the carrage return you must use backslash “” as in “\r”, not forward slash as in “/r”. Your postings seem to go back and forth in the usage. Make sure that it is “\r” in your script.

Take a step back and work on the script bit by bit.

Get rid of the pipe and everything after it and see what the echo is actually echoing.

#!/bin/sh

/bin/echo -e "start  $1   \rend"

When you call script.sh POWR! your output should be something like:

endrt  POWR1

NOTE: The carage return returns the cursor to the beginning of the line so the echo first prints "start POWR1 " then returns the cursor to the beginning and prints “end”.

If you run that script you will see whether or not the script is interpreting the $1 as a variable or as a string literal (you used the term correctly). Once you see something like that, remove the “start” and “end” from the echo statement and readd back in the pipe. If it doesn’t work now the problem isn’t the echo but the nc command.

The delimiter is space so you might need to escape the spaces, though I think the quotes are enough to put it all in $1.

./script.sh "POWR0\ \ \ \r"

And again, by focusing on just getting the echo to work right it will be lot easier to test this out to see what is happening. For example:

#!/bin/sh

echo "Argument 1 = $1"
echo "Argument 2 = $2"

When something doesn’t work, break it down into tiny pieces and work on them one by one until you get it to work rather than trying to get everything working all at once.

Yeah those are just typos. Its weird to use the backslash when typing. thank you though.

This is great advice (and something I constantly seem to forget). Thanks and I’ll report back.

I’m not in front of an actual sh, but I’ve been playing around with an online bash emulator and I’m beginning to think the issue with both the exec commands and this is the three spaces. For instance running executing this script:
/bin/echo -e $1
with:
./script.sh POWR0 \r
returns:
POWR0
As excepted, and putting stuff after the carriage return “overwrites” the initial output as you detailed above. However, there’s no real way for me to be sure that all 3 spaces are included before the carriage return.
SO, I executed:
./script.sh POWR0 .\r
and it returned
POWR0 .
with only one space between the zero and the period! I feel like this condensing of 3 spaces into 1 has happened a few times in random situations (or at least in a pattern I haven’t been able to recognize. It even happened earlier when I was typing in something on this thread).
Putting this in the actual script:
echo -e "$1 .\r"
and executing:
./script.sh POWR0
returns
POWR0 .\r
so maybe that’s the answer (though without the period), but I could’ve SWORN i already tried that. I’ll report back.

EDIT: haha it happened again. In that last Preformatted Text i wrote, the POWR0 .\r I definitely have typed 3 spaces in both instances but the forum prints it as 1 space…

Be wary of using how a web based bash emulator or this forum treats spaces as how it will actually behave. Be default web browsers will treat several spaces in a row as a single space so what you might be seeing is just a side effect of how the web browser renders the page. The proof will be when you run your tests in front of an actual shell.

If the actual shell is also condensing the spaces (which I find hard to believe), use "\ \ \ " for the spaces. That will escape them and keep the echo hopefully from condensing them

of course, just reporting weird findings that might describe some of my issues. I’ll hold all judgments until I try on the Pi

I’ve tried to “escape” out spaces with a slash many times. It doesn’t seem to work that way and everything I find on the web regarding the backslash characters doesn’t seem to list anything for spaces (closest is /0 for null). Any time I tried that in the exec binding item configuration or the rule I would get an error or some other undesirable behavior. Just saying, I don’t think typing a backslash then a space reads into the shell as a space.

Actually the opposite. It may not read as a space in the Exec binding. In the shell if you, for example, need to cd to a folder with a space in the name you use "\ ".For example here is how I would cd to my “Calibre Library” folder on my Linux machine:

cd /mnt/media/Calibre\ Library/

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