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)
Hi @stu,
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.
Unfortunately 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 uname
and/or 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.