make inferred workspace dir consistent with actual one in builds

[gmishkin]

I want to make the workspace path you get when you look at $BUILD_WORKSPACE_DIRECTORY inside the target you're running, be consistent with the value you get if you do $(dirname "$(dirname "${BASH_SOURCE[0]}")") in a tools/bazel script. I'm using the latter form of this as part of a startup option in my wrapper.

I am using the tools/bazel script to $BAZEL_REAL run the full wrapper target, which takes the rest of the args, does some logging, and invokes BAZEL_REAL again with the original args. But it also needs to set that startup option when it does so, to avoid thrashing the server. To do so it uses BUILD_WORKSPACE_DIRECTORY.

What I noticed is that it was thrashing the server anyway. When I dug in, it turned out the issue was that inside tools/bazel it was passing

--host_jvm_args=-Djavax.net.ssl.trustStore=/Users/geoff/proj/./cacerts`

But inside the target running via bazel run, it was passing

--host_jvm_args=-Djavax.net.ssl.trustStore=/Users/geoff/proj/cacerts`

Even though they're logically the same file, bazel doesn't realize that, especially when the path is being passed to an arbitrary JVM flag. So it restarts the server each time.

Removing the leading ./ in the constant prevents the server restarts, and seems safe because that constant is only ever used in os.path.join() which is aware of how to combine path components.

I also included a test to show the difference, but you can remove it if you think it's silly.

[gmishkin]

@philwo errr... should I start passing shell=True to subprocess.Popen() on Windows?

To get it to be able to run batch files.

[philwo]

@gmishkin Sorry for not getting back to you. Your fix looks good to me - thanks for the debugging!

Regarding shell=True, the Python docs say this:

The only time you need to specify shell=True on Windows is when the command you wish to execute is built into the shell (e.g. dir or copy). You do not need shell=True to run a batch file or console-based executable.

The test failure you're seeing is probably due to Windows just not supporting running executables that lack an .exe or similar suffix. Thus, running tools/bazel would never work on Windows anyway (it would have to be called tools/bazel.cmd or something like that).

I think we have to add special logic to delegate_tools_bazel so that it looks at different files on Windows (maybe we could try tools/bazel.exe, tools/bazel.cmd, tools/bazel.bat in that order?)