Avoid using user-controlled paths as regex patterns (fix #1084)

[AnyOldName3]

This might not work on MacOS, but is fine on Linux and Windows.

Otherwise, #1084 happens, and building the library after cloning it to a path like C:\C++Libraries\KTX-Software doesn't work.

If realpath isn't available on MacOS, then I guess $(pwd) could be run through a sed script that regex-escaped it, but there are still some edge cases that that wouldn't handle well. e.g. with symlinks.

Fixes #1084.

[CLAassistant]

All committers have signed the CLA.

[MarkCallow]

realpath is available on macOS.

[MarkCallow]

macos's realpath does not take any options except -q to silence warnings. This is the reason for the CI build failure.

Please find an alternative way, at least for macOS.

[MarkCallow]

Otherwise, #1084 happens, and building the library after cloning it to a path like C:\C++Libraries\KTX-Software doesn't work.

Do you see paths with '' path separators in git bash or bash running under WSL on Windows?

Wouldn't it be easier to update the RE to allow either type of path separator?

[AnyOldName3]

In this case it's nothing to do with the path separator - it's a Unixy cygpath-style path here when running on Windows, so only has forward slashes. The problem is that there are plenty of other characters that are legal in paths that are interpreted differently in a regex. On my machine, it's that I had two consecutive + characters making it an invalid regex, but there are other obvious examples that make a regex-based approach unreliable. E.g., while it's illegal on Windows, on Unix, you could make a directory called .*, and that's pretty obviously going to match directories other than itself if interpreted as a regex. Lexical path comparison is already fraught with trouble, and including arbitrary/user-provided strings into regex always requires escaping them, which is why I went for something more reliable, although it turned out not to be portable.

[MarkCallow]

Closing in favour of alternative fix in PR #1088.

Thanks for the report and this PR.

[AnyOldName3]

Somehow I'd missed the relevant paragraph in the Bash manual about quoting meaning something different within a [[ test. That solution's much simpler.