Hello

I've been using hcl2json to verify some terraform files - it's working great, but I've found a small snag in escape sequence handling that results in ambiguous string value output.

It's probably easiest to just show an example:

resource "my_type" "my_resource" {
  my_text_value = "$${data.vault_generic_secret.my_secret.data[\"xyz\"]}"
  my_expr_value = data.vault_generic_secret.my_secret.data["xyz"]
}

The above generates this json:

"my_type": {
  "my_resource": [
    {
      "my_expr_value": "${data.vault_generic_secret.my_secret.data[\"xyz\"]}",
      "my_text_value": "${data.vault_generic_secret.my_secret.data[\"xyz\"]}"
    }
  ]
}

where both my_text_value and my_expr_value get output as the same literal string because $${ is the escape sequence for a literal ${. (Other escape sequences also get converted to their literal values - \r, \n, etc).

I was trying to do some downstream processing on the attribute values with some very basic expression evaluation - it would be good if there was some sort of --no-unescape switch to preserve the literal string values as they appear in the terraform files:

"my_type": {
  "my_resource": [
    {
      "my_expr_value": "$${data.vault_generic_secret.my_secret.data[\"xyz\"]}",
      "my_text_value": "${data.vault_generic_secret.my_secret.data[\"xyz\"]}"
    }
  ]
}

That way it'd be possible to differentiate an expression string from a literal string with $${ escapes...

(For now my code is just going to assume no-one actually uses the $${ escape sequence so if a string attribute contains ${ it'll trigger my evaluation logic - I don't think that'll be a problem for my use-case, but it would still be nice to remove the ambiguity).