Review of unix scripts

[markusschuh]

Resolve the warnings & implement most important recommendations of ShellCheck

[CLAassistant]

All committers have signed the CLA.

[hohwille]

@markusschuh Thanks for this PR. Contains some great fixes and improvements. Also should finally allow spaces in installation paths. However, a few changes seem to introduce bugs and some might need to be discussed (maybe my knowledge of bash is just incomplete). Please have a look at my review comments. Thanks in advance.

[hohwille]

I also was not aware of ShellCheck before. Maybe we can even integrate it into travis build so we get warnings/errors if we do not follow best practices. However, only makes sense if it is not too strict.

[markschuh]

Best is to use ShellCheck even before code is commited, e.g. with help of the shellcheck vscode extension.

Different Install exists, on Windows it could be run native (installed via scoop), inside WSL (win10) or as a docker container.

ShellCheck can be configured to ignore specific checks, Still missing is an option to ignore via priority. (e.g. don't show recommendations)

TravisCI integration exists and shellcheck is meanwhile preinstalled there.

The only "challenge" for devon-ide is, that the shell scripts can't be selected by file ending, but need to be listed all by name. I guess, it would be more helpful for CI/CD and browser syntax highlighting, if the .sh ending were used. But this has new challenges during deployment, when the file endings will be removed there.

[hohwille]

Awesome, but according to shellcheck I seem to be stupid:
vscode-shellcheck/vscode-shellcheck#50

[markschuh]

I have added your CRs ( except the postponed replacement of doGetVariable ). I'm unsure, what happens with this PR if I upgrade to lastet commit in my forked repo, so I do not yet push the merge from my local clone to remote. The conflicts still allow auto resolving - so I assume, the merge of pull request can be handled,

N.B: the vscode-shellsheck is a linter. And as some other linters I have seen - and with the default setting "onType" - it should underline a new entry line like echo $@. If not, I guess your shellcheck can't be found by the linter. Documentation may not be perfect - but I have seen much, much worser extensions on the vscode marketplace.

[hohwille]

Even though this PR itself was not merged and has too many conflicts now, I worked your bug fixes, suggestions and improvements into the code. I will close this PR now. Thanks for your work, experience in bash, bugfixes and hints.