### Terraform Version ``` Terraform v1.2.0-beta1 on linux_amd64 ``` ### Expected Behavior From Terraform v1.0 onwards, our compatibility promises commit us to backward compatibility only with the explicitly-selected machine interfaces, and not to human-oriented output. The intent of that commitment was to support the various situations where the caller _explicitly_ requests machine readable output, via extra command line options like `-json` or `-raw`. It does not apply to any default output, even if that output happens to be relatively simple and amenable to line-based processing. ### Actual Behavior The `terraform state -help` output has a very stale old claim about the state commands being suitable for machine parsing: ``` $ terraform state -help Usage: terraform [global options] state [options] [args] This command has subcommands for advanced state management. These subcommands can be used to slice and dice the Terraform state. This is sometimes necessary in advanced cases. For your safety, all state management commands that modify the state create a timestamped backup of the state prior to making modifications. The structure and output of the commands is specifically tailored to work well with the common Unix utilities such as grep, awk, etc. We recommend using those tools to perform more advanced state tasks. ``` (Notice the last paragraph above.) I believe the original intent was not to encourage _automation_ or _scripting_ based on these results, but rather just to say that it might be helpful sometimes for humans to filter and process the output _on a one-off basis_ in order to answer specific questions. Regardless of original intent, this new message is not consistent with our current intentions, and so we should remove it altogether to avoid being confusing. While we're there, we should probably also remove or adjust the last sentence of the penultimate paragraph, which makes a claim that these command always create a backup even though that has not been true for any non-local backend since Terraform v0.9. ### Additional Context Note that the main supported way to process the state programmatically is to run `terraform show -json` and then parse the resulting JSON output. That would be the most appropriate way to achieve anything that involves routine machine processing of Terraform state contents, and not any of the commands under the `terraform state` prefix. (This was originally raised as part of #21779.)