I have a terraform script that needs to behave differently based on what OS it happens to be running on. Specifically, I’m haveing an issue executing local-exec shell scripts. local-exec normally runs the commands with /usr/bin/sh -c. The script I have won’t run with sh but requires bash. I want to set the interpreter = /usr/bin/bash -c when necessary but I can’t find any easy way to find out what environment I’m executing on. (The issue is on RHEL, /usr/bin/sh calls bash but on Ubuntu /usr/bin/sh calls sh. ) I can’t change the interpreter to always point to /usr/bin/bash because on the MAC, that doesn’t resolve to anything, although it did fix the issue on Ubuntu)
There is no first-class feature for recognizing different variants of Unix in a Terraform configuration.
I’m not a macOS user so I might have an incomplete understanding, but I’ve heard from my colleagues that modern macOS doesn’t include bash at all, and so if your script specifically requires bash then you may need to install it separately in order to successfully run the script on macOS.
With that said, if you are able to make
bash available on all of the systems where you will apply this Terraform configuration, you might be able to get a suitable result by setting the interpreter to
/usr/bin/env bash. This
env program is intended as a way to run a program with a modified environment, but as part of its work it also looks in
PATH to find the specified program, and so it can also double as a way to force a program that normally requires an absolute path to consult the
PATH environment variable instead. As long as you have a
bash program somewhere in one of the directories in
PATH, that command line should find it.
local-exec is indeed a bit of a portabililty hazard, given that it directly interacts with the host operating system. If my above solution doesn’t work for you for some reason then another more involved idea I might suggest is to write a wrapper script using portable shell techniques whose only job is to recognize which platform it’s running on, and then launch the real script using the appropriate interpreter. That way you can implement whatever logic you want inside the wrapper script, such as consulting the output of
lsb_release, or sniffing for a few different possible shell locations as a heuristic.
I was actually able to rewrite the command so it would work on all platforms that I need.
@stu Would you be able to share a snippet of how you achieved this? It would help one and all. thanks for your time.