Execute source using /bin/bash not /bin/sh

[shinglerb]

Attempting to execute source in /bin/sh doesn't work if /bin/sh isn't bash

[knet-ci-bot]

Can one of the admins verify this patch?

[fabbione]

in that case, the bash´ism should be removed. /bin/bash is not available on all systems.

[oalbrigt]

It works fine if you replace "source" with "." (tested with bash, dash and sh on FreeBSD):
output = subprocess.check_output(". {} && env -0".format(env_file), shell=True, executable="/bin/sh")

[knet-jenkins]

Can one of the admins check and authorise this run please: https://ci.kronosnet.org/job/fence-agents-pipeline/job/PR-547/1/input

[oalbrigt]

It seems like replacing source with . should fix this issue.

[DEmmons]

I can confirm this still causes issues on Ubuntu 24.04, for what it's worth. I ran into it with the fence_openstack agent. Two good resolutions have been suggested, and it seems that determining which one is better needs to be informed by the intention of compatibility:

• If the intention is to continue to assume the shell is bash (as the current code does), and not worry about systems that do not have bash available, this PR is just right. while it's not always the default shell, bash is available for most *nix environments that could run these agents, and even things like OSX. Ostensibly this also helps keep the behavior predictable.
• If the intention is to run in as many POSIX systems as possible with their default shell, the suggestion of using a "." instead of the bash builtin "source" is probably the right call, though this assumes the line will be interpreted the same way in each shell. While that can be understood to be a basic goal of the POSIX standard, here we are, discussing this.
• if both of these approaches leave out compatibility for an important target environment, handling beyond a one-line change may be needed, but nothing comes to mind

To sum up, unless I've misunderstood project goals, this PR looks like the right solution.

[sherrardb]

i have just come here to add my "me too" to the comment from @DEmmons. i have stumbled across the same issue with fence_openstack, and i am also eagerly awaiting a solution that doesn't involve me manually patching fencing.py. :-)

per @DEmmons third bullet

• if both of these approaches leave out compatibility for an important target environment, handling beyond a one-line change may be needed, but nothing comes to mind

if there is reluctance to enact either of the first two options, then it seems that allowing executable to be passed as an optional argument to source_env(), and with a default of /bin/sh should satisfy all comers while also preserving the current behavior for those for whom it is not broken.