alt bash path support

[hackacad]

Signed-off-by: hackacad [email protected]

Description

Be more liberal about the location of bash

Issues Resolved

required for upstream FreeBSD support

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[opensearch-ci-bot]

✅   DCO Check Passed fbc72c2

[opensearch-ci-bot]

✅   Gradle Wrapper Validation success fbc72c2

[opensearch-ci-bot]

✅   Gradle Precommit success fbc72c2

[dblock]

start gradle check

[dblock]

So what could go wrong when changing #!/bin/bash to #!/usr/bin/env bash? Is there anything written about what the shebang is supposed to be across *nix'es?

[opensearch-ci-bot]

✅   Gradle Check success fbc72c2
Log 352

Reports 352

[hackacad]

Using env is the recommended way in POSIX.
https://www.google.com/search?tbm=bks&q=linux+unix+shell+script+usr+bin+env

Using hard coded path to bash is a common issue (of course, there's a built-in shebang_fix in FreeBSD Makefile/built system, but using a env should make it more portable for every nix OS)

(env should always be available on every UNIX/Linux at /usr/bin/env)

[dblock]

cc: @nknize for a quick second look, but this makes sense to me

[hackacad]

cc: @nknize for a quick second look, but this makes sense to me

just ftr:
this is already used in some OpenSearch scripts like
/dev-tools/atomic_push.sh
/gradlew

[dblock]

cc: @nknize for a quick second look, but this makes sense to me

just ftr:
this is already used in some OpenSearch scripts like
/dev-tools/atomic_push.sh
/gradlew

Let's then also fix anywhere we're not doing this in this PR?

[hackacad]

Let's then also fix anywhere we're not doing this in this PR?

These are the tools that are necessary during/for runtime.
I’m not sure if the other ones have any dependencies or checksums which might be effected then.
I’ll have a look at it.

[hackacad]

I rethought the idea of using env for start-up scripts. In most cases, this should work, but I'm not aware of every use-case, especially in custom build Linux/Unix systems.
Is there a way of fixing that during build and create a separate FreeBSD version? I created a ticket on FreeBSD side with all necessary fixes.
I'd agree if you refuse that PR, which compensates for the shebang (that could be resolved during package building).

[dblock]

I am going to go off https://unix.stackexchange.com/questions/206350/what-is-the-difference-if-i-start-bash-with-bin-bash-or-usr-bin-env-bash and adopt the more portable version that you're suggesting and merge this. Note that I read the concerns of malware preempting bash in PATH, if someone thinks those apply we can always reconsider and revert.

If you have time, mind taking a look at all the other places we use bin/bash, such as dev tools and bulk replace them? Thanks.

[dblock]

Is there a way of fixing that during build and create a separate FreeBSD version? I created a ticket on FreeBSD side with all necessary fixes.

We'll leave that ticket open. Making code portable is the first step, we don't want to be patching bash scripts during packaging unless we must. Next, if we're going to be releasing a FreeBSD version, we will need to be signing binaries and running the massive integration test suite on them, which is definitely possible but I can't promise timelines or releases.