Either give up the fragile Git sh support, or address it more explicitly! about space_test HOT 4 OPEN

So, cases to be unified by the time we arrive to the build command in the makefiles:

1. Running natively in sh (either Win or not) vs. running via the Windows .cmd frontend (-> how to run build.sh at all?)
2. BB vs Git vs. some other shell (-> what path to add to build.sh?)

Also, in the makefiles, we are in an sh shell child context, but the make tools will have their own idea of what's going on!

1.:

• Running .sh natively (via run_cases):
  _sh_ is not set
  SHELL is set, and valid
• Run via Win frontend:
  _sh_ is set (to whatever can accept a .sh script as an argument directly)
  SHELL will also be set by the tools, but invalid (likely just a fake /bin/sh)

OK, so, run_cases ought to normalize this to a common shell variable -- keeping its path transparently in the native format!

2.:

OK, I think just adding the _engine dir (or wherever that build.sh is) to the PATH would eliminate the need to explicitly specifying its location in the makefile... It's a bit shaky tho: it would need to be made absolutely sure that the _engine dir is prepended to the PATH, and perhaps the script would also need to be renamed to sg. less generic to mitigate the risk of accidental mismatches with other such things also on the PATH!

<Mmm... An hour later...>

Dammit, extending the PATH already requires dispatching on the host's idea of what it should look like... :-/
And no, just the ':' vs. ';' is not enough...:

get_path_sep(){
#!! Umm, OK, yeah, but... Well... On Windows, but with an env. where the shell does
#!! path conversion from C:/... to /c/..., then just switching path-sep. won't help!
    ...    
}

from space_test.

The problem is that e.g. in the Git shell, which meticulously fakes everything, $0 is still not converted! :-(
That prevents us from using it as the dir anchor as-is.

So... E.g. https://stackoverflow.com/a/13701495/1479945:

echo "/$winpath" | sed -e 's/\\/\//g' -e 's/:///'

But, better yet, should use cygpath instead! -- The problematic environments ship with one anyway! (That itself is quite a good sign that it's a MinGW-like env!)

from space_test.

Incredibly, cygpath -m for some reason screwed up paths for me, replacing the ":" after the drive (and quotes around the path) with some unprintable chars! :-o

from space_test.

So far so good though (as of v0.13), so keeping the status quo...

from space_test.