Added check for sed return code, switched to bash and also properly i…

[Keeper-of-the-Keys]

…nserts newlines on Linux.

[peternewman]

A few comments

[peternewman]

As per the discussion in the issue, this needs reverting as it won't work on FreeBSD:
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/linux-users/shells.html

[Keeper-of-the-Keys]

bash is not the default shell but it is available, whether installed or not is a different story but we can and should make it a dependency.

grep -R '#! /bin/bash' . | wc -l returns 41 on the OLA source directory so saying we depend on bash is reasonable if not necessary.

In addition to that /bin/sh causes a crapshoot of unpredictable shell interpreters where each distro is running it through whatever sh-like solution they happen to like and stuff works or doesn't work while bash is bash is bash (except maybe for version stuff but unless we use some cutting edge bash feature we're not likely to run into that).

[Keeper-of-the-Keys]

And grep -R '#!/bin/bash' . | wc -l returns 9

[peternewman]

bash is not the default shell but it is available, whether installed or not is a different story but we can and should make it a dependency.

Why? If you've tried to install OLA on say Windows, adding even more dependencies just makes it even harder, likewise it's more slightly different versions of stuff to support, it's taken us long enough to get most stuff compiling across Linux, OS X, *BSD and Windows. TBH if we were going to do anything, adding perl would probably be the sensible choice, as it's standardised, has been around forever so is well deployed and would also fix these sed incompatibilities.

grep -R '#! /bin/bash' . | wc -l returns 41 on the OLA source directory so saying we depend on bash is reasonable if not necessary.

Try running that again in a clean checkout, you'll find all those ones with spaces are from Makefile magic; I don't know what it does if you don't have bash, but there would be an option to do some magic.

In addition to that /bin/sh causes a crapshoot of unpredictable shell interpreters where each distro is running it through whatever sh-like solution they happen to like and stuff works or doesn't work while bash is bash is bash (except maybe for version stuff but unless we use some cutting edge bash feature we're not likely to run into that).

It's really not that hard, there are even tools to help:
https://wiki.ubuntu.com/DashAsBinSh
https://linux.die.net/man/1/checkbashisms

And grep -R '#!/bin/bash' . | wc -l returns 9

So these are the actual ones we'd need to look at, GitHub finds 7:
https://github.com/OpenLightingProject/ola/search?q=%22%2Fbin%2Fbash%22&unscoped_q=%22%2Fbin%2Fbash%22

So the ones in include/ are the ones actually run automatically during the build. I was about to have to agree with you, then I looked a bit more carefully:

ola/include/ola/Makefile.mk

Line 48 in d101097

sh $(top_srcdir)/include/ola/make_plugin_id.sh $(top_srcdir)/common/protocol/Ola.proto > $(top_builddir)/include/ola/plugin_id.h

I'm no expert, but I'm fairly confident that means it runs it via sh and will therefore actually use your sh interpreter rather than whatever is in the shebang line. So we should probably remove that bug in the files by changing /bin/bash to /bin/sh, but its probably having no impact to the build.

[Keeper-of-the-Keys]

Why? If you've tried to install OLA on say Windows, adding even more dependencies just makes it even harder, likewise it's more slightly different versions of stuff to support, it's taken us long enough to get most stuff compiling across Linux, OS X, *BSD and Windows. TBH if we were going to do anything, adding perl would probably be the sensible choice, as it's standardised, has been around forever so is well deployed and would also fix these sed incompatibilities.

If bash was some exotic shell that was not in wide use I would absolutely agree with you, however bash is actually very well established to the point that it is even available for windows iirc, it may not be an ISO standard but bash X.Y on OS A will behave the same and bash X.Y on OS B (and I think this may in general even apply for X.y and X.z)

(...)

It's really not that hard, there are even tools to help:
https://wiki.ubuntu.com/DashAsBinSh
https://linux.die.net/man/1/checkbashisms

This script that we are currently discussing is a live example of /bin/sh not behaving the same across different platforms while on OSX it was doing what you expected it to do it was not doing so on Debian based distros that use dash for sh and this script was not doing anything crazy complicated but the different globbing/parsing behaviors of the different sh implementations killed consistent results.

So these are the actual ones we'd need to look at, GitHub finds 7:
https://github.com/OpenLightingProject/ola/search?q=%22%2Fbin%2Fbash%22&unscoped_q=%22%2Fbin%2Fbash%22

I think we have better things to do with our time bash is easily installed and widely available.

Also note that according to the documentation about installing on Windows bash is the actual shell used there through mingw (though the MSYS part of mingw seems to be dead so that may not be wise, but an alternative is out there - MSYS2 ) and MS has released a "Linux on windows" environment this year which seems to obviate the need for mingw.

https://wiki.openlighting.org/index.php/Building_OLA_for_Windows
https://www.msys2.org/
https://itsfoss.com/install-bash-on-windows/

Both MSYS and MSYS2 provide bash shells as does "Linux on Windows", FreeBSD may not ship with it but it's installable with ease

So the ones in include/ are the ones actually run automatically during the build. I was about to have to agree with you, then I looked a bit more carefully:

ola/include/ola/Makefile.mk

Line 48 in d101097

sh $(top_srcdir)/include/ola/make_plugin_id.sh $(top_srcdir)/common/protocol/Ola.proto > $(top_builddir)/include/ola/plugin_id.h

I'm no expert, but I'm fairly confident that means it runs it via sh and will therefore actually use your sh interpreter rather than whatever is in the shebang line. So we should probably remove that bug in the files by changing /bin/bash to /bin/sh, but its probably having no impact to the build.

As far as I know you are correct.

[FloEdelmann]

@Keeper-of-the-Keys You can use set -e to exit immediately with a non-zero exit code whenever one command in the script fails.

[Keeper-of-the-Keys]

@Keeper-of-the-Keys You can use set -e to exit immediately with a non-zero exit code whenever one command in the script fails.

But that will prevent understandable error messages no?

[peternewman]

@Keeper-of-the-Keys You can use set -e to exit immediately with a non-zero exit code whenever one command in the script fails.

But that will prevent understandable error messages no?

Good call @FloEdelmann . I don't think they particularly need to be understandable @Keeper-of-the-Keys , have you seen some of the compiler output. TBH the sed error will probably tell a developer more useful info than a generic "it's failed" message, and most end users will either use that to go digging or more generally just open an issue/write on the mailing list, so I'm not sure that's a very big consideration.

[Keeper-of-the-Keys]

@Keeper-of-the-Keys You can use set -e to exit immediately with a non-zero exit code whenever one command in the script fails.

But that will prevent understandable error messages no?

Good call @FloEdelmann . I don't think they particularly need to be understandable @Keeper-of-the-Keys , have you seen some of the compiler output. TBH the sed error will probably tell a developer more useful info than a generic "it's failed" message, and most end users will either use that to go digging or more generally just open an issue/write on the mailing list, so I'm not sure that's a very big consideration.

ATM the would get both a sed error line and a user readable message but I hear you.
I added set -e to the top of the script and removed the check.

[peternewman]

Ping @Keeper-of-the-Keys and @FloEdelmann as original writer of the sed command. I've finally had a chance to have a proper look and I think we can remove the failing new-line insertion by simplifying the sed command, see my version here:
#1608

I started out by commenting what the original one did:
ae4879d#diff-e27975dbf242f99283db8699d57acd1cR33-R39

Essentially if we don't concatenate the lines, and then try and replace the newlines, but instead simply put an escaped newline at the end of each actual line (apart from the last one), and then quotes around it (currently apart from the first and last lines to match the existing behaviour, it becomes a simpler drop-in replacement. So far I've only tested this on 16.04/GNU sed 4.2.2, but given it's only using a subset of the existing functionality, I think it should be fine.

[peternewman]

I assume s/\\\/\\\\\\\/g is trying to escape a backslash, or an escaped backslash? I don't think there are currently enough backslashes, you've got three replaced with seven. I think the shell will eat half of them, leaving s/\/\\\/g, which sed would interpret as an escaped / followed by a \ and escaped /, but with no substitution operators. I think you actually want four and eight, which boils down to two/four and therefore one/two. See the quote escaping for example.

[Keeper-of-the-Keys]

We're escaping backslash:

• first for bash so sed 'sees' only 2
• then for sed since backslash has significance there too

[peternewman]

* first for bash so sed 'sees' only 2

We'll need one per sed backslash (escaping or real), rather than one in total.

* then for sed since backslash has significance there too

Likewise here.

I believe you're trying to logically replace \ with \\?

[Keeper-of-the-Keys]

Yes because backslash also has significance in C into which the readme is ultimately converted.

[FloEdelmann]

Disclaimer: I'm not an sed expert 😄

I think @peternewman is right though with the number of backslashes; and I also think we should add more comments to explain each part of the sed command.

If we could make the command easier by excluding the line length limitation from the exported file, that'd make it a lot easier.

[peternewman]

Disclaimer: I'm not an sed expert smile

Heh, fair enough!

I think @peternewman is right though with the number of backslashes; and I also think we should add more comments to explain each part of the sed command.

I've covered that bit in my version here #1608 .

If we could make the command easier by excluding the line length limitation from the exported file, that'd make it a lot easier.

I'm tempted to disagree with you here, aside from my preference for keeping the length limitation, I think it will actually make the command more technically complex. If you ignore the stuff about escaping things, which will be common regardless. If you use my version, we're essentially just adding a " to the start and \n" to the end of each line. There's a little bit of trickery to not begin with a ", although that could be dropped if other parts of the script were tweaked, and to not end with a \n, so it looks nicer, but that's essentially it. If we try and merge it into one line, we need to delete all the real newlines that exist to merge it, then we're into the territory of possibly having to deal with carriage returns too on Windows depending on auto CRLF settings in Git clients and all sorts of complexities. If we don't touch them and just decorate the start and the end of the line it should work regardless of the actual line end characters as they remain untouched and intact.