A map value
The export has to hold JSON, because Terraform only parses primitives from an environment variable
region = "eu-west-1"
tags = {
env = "prod"
} Convert .tfvars assignments into TF_VAR_ exports for a shell or a pipeline. Two things catch people: complex values must be JSON, and these are the lowest-precedence source there is.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Convert. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
The export has to hold JSON, because Terraform only parses primitives from an environment variable
region = "eu-west-1"
tags = {
env = "prod"
}There is no expression language while a tfvars file is read, so this cannot work at all
region = var.region
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Environment variables are the lowest-precedence source. A terraform.tfvars or an *.auto.tfvars in the working directory silently wins.
Instead:Check the directory for a tfvars file setting the same name. Use -var on the command line if you need to override everything.
A list or a map in an environment variable must be JSON. TF_VAR_tags='{env="prod"}' fails as a type mismatch, which points at the declaration rather than the value.
Instead:Use JSON: TF_VAR_tags='{"env":"prod"}'.
TF_VAR_REGION does not set var.region. On Windows the shell hides the difference, so the same script behaves differently across platforms.
Instead:Keep everything after TF_VAR_ identical to the variable name, character for character.
The precedence order explains the commonest complaint about TF_VAR_, which is that setting it appears to do nothing at all.
Environment variables, then terraform.tfvars, then terraform.tfvars.json, then every *.auto.tfvars in alphabetical order, then -var-file and -var on the command line, with later winning. So exporting TF_VAR_region while a terraform.tfvars in the working directory also sets region has no effect, and nothing warns you.
Terraform parses a primitive from an environment variable directly. A collection has to be valid JSON, so TF_VAR_tags='{"env":"prod"}' works and the HCL form with = between key and value does not. The error is a type mismatch rather than a syntax complaint, which sends people looking at the variable declaration.
TF_VAR_REGION does not set var.region. This bites hardest on Windows, where the shell treats environment variable names as case-insensitive and Terraform does not, so a script that works in one shell fails in another with no visible difference.
Every process the shell starts inherits it, it is readable from /proc for the process lifetime on Linux, and typing the export puts it in shell history. A tfvars file with restrictive permissions is often the safer option, and reading from a secret manager at the point of use is better than either.
Anything with a space, a dollar sign, a backtick or a bracket needs quoting, and single quotes are the form that does not interpret. A value containing a single quote needs the '\'' dance, which the output here already does.
There is no expression language available while it is read: no variables, no locals, no functions. So a reference in a tfvars file is a parse error rather than something to convert, and the logic belongs in a local in the configuration.