Use apparent executable name instead of hard-coded "terraform" when suggesting followup commands to run

[skeggse]

Current Terraform Version

Terraform v0.14.5

Use-cases

Improve developer experience while using Terraform with a custom authentication wrapper by printing argv[0] instead of terraform when recommending the user run terraform init (and similar directives):

https://github.com/hashicorp/terraform/blob/6697245c18dad6848e7647598dda1ab04c2680ca/terraform/resource_provider.go#L4

Attempted Solutions

Tried using exec -a tf terraform "$@" to invoke terraform in a way that might override this printing, but alas it's a static string.

Proposal

Replace occurrences of the terraform binary with argv[0] in warning/error/instruction output text.

[apparentlymart]

Hi @skeggse,

I do agree with you that Terraform should ideally honor whatever executable name the user has selected, because it can be confusing when you've e.g. got multiple executables in PATH to run different versions for different configurations on the same system.

With that said, I think something else in the mix here is interfering such that just using argv[0] wouldn't be sufficient to get the result you want, because when I tried running Terraform using exec -a foo as you indicated here Terraform reported in the trace log that it detected the arguments like this:

2021-03-18T15:22:09.927-0700 [INFO]  CLI args: []string{"/home/me/bin/terraform", "version"}

I think the problem here is that the terraform command typically run directly starts by forking a child process which does all of the "real work", because the parent process is responsible for catching and handling crashes in the child process. That child process is the one that's printing all of these messages, and so it would still pick up its name as terraform regardless of what argv[0] is set to in the parent process.

I think that difficulty, combined with the fact that Terraform includes a non-trivial amount of messages like this, unfortunately means that we're unlikely to be able to prioritize addressing this in the near future, but I agree that it'd be nice to support it so I'm going to leave this issue open to represent the use-case.

I think the next step here would be to come up with a technical design for this which both accounts for the child process difficulty I mentioned above and also creates a design with good separation of concerns so that only a single component of Terraform (probably package main) is responsible for deciding what this executable is called, rather than having various uncoordinated calls to directly look up argv[0] all over, so that we can make sure they all act consistently and so we can potentially decide differently in unusual situations like unit tests. Once we have a good strategy for what this might look like, I think we'll also need to do an inventory of all of the situations where Terraform prints messages like this and then decide on a non-disruptive way to update them all, possibly over a few separate changes just because this seems likely to be a cross-cutting concern and so likely to collide with other work.

[apparentlymart]

I don't have any significant update to share on this, but FWIW we've subsequently removed the mechanism that I was describing earlier which caused Terraform to immediately fork itself on startup.

That mechanism was there as a very coarse way to detect Go runtime panics and annotate them with some additional context to help users file a bug report, but we've subsequently found ways to solve that problem more surgically, so no immediate forking is required.

---

The other problem that Terraform still has many different messages (error and otherwise) that suggest Terraform commands to run, and that they are generated in various parts of the codebase with differing access to relevant context, remains to be reckoned with.

If someone is thinking about designs for this in future, I would draw attention to how we already have an environment variable TF_IN_AUTOMATION which, if set, causes us to make a best effort to avoid suggesting commands to run at all, since in that case we assume that the user is not directly running Terraform CLI. Supporting that consistently presents a similar challenge of needing to get that extra context into all of the parts of Terraform that might generate such messages, and so maybe we can find some way to better propagate these two pieces of information together: should Terraform generate recommendations about other commands to run, and if so which command name should it use when doing so?