main: Try to expand arguments starting with "@" from files on disk #2457
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a GCC-like behavior where we preproces the argument vector by trying to treat any argument starting with "@" as a placeholder for arguments loaded from a given filename.
As with GCC, if the remainder of the string cannot be used as a filename to open and read, the original argument is retained literally. However, if it is possible to open and read a file of the given name then we take that as sufficient evidence of the operator's intent to read from that file and will fail with an error message if the file contents are not acceptable syntax.
This uses the same upstream library as we've already been using for the
TF_CLI_ARGS
... environment variables. Since main.go was quite overcrowded with various different concerns, the handling of those environment variables also moves into the new arguments.go file here, since the two share an upstream dependency and both involve simplistic substitutions and insertions into the argument vector. The observable behavior of the environment variable handling should not be changed in any way by this commit.For the moment this is just a draft to play with the idea from #2429. I'm going to add some commentary in that issue about some quirks of the upstream library we're using here that might be concerning, some (but not all) of which are currently reflected in the test failures on this PR.