terraform/website/docs/cli/commands/console.html.md

125 lines
2.9 KiB
Markdown
Raw Normal View History

2016-11-14 07:57:28 +01:00
---
layout: "docs"
page_title: "Command: console"
sidebar_current: "docs-commands-console"
description: "The terraform console command provides an interactive console for
2021-07-23 22:31:43 +02:00
evaluating expressions."
2016-11-14 07:57:28 +01:00
---
# Command: console
The `terraform console` command provides an interactive console for
evaluating [expressions](/docs/language/expressions/index.html).
2016-11-14 07:57:28 +01:00
## Usage
main: new global option -chdir This new option is intended to address the previous inconsistencies where some older subcommands supported partially changing the target directory (where Terraform would use the new directory inconsistently) where newer commands did not support that override at all. Instead, now Terraform will accept a -chdir command at the start of the command line (before the subcommand) and will interpret it as a request to direct all actions that would normally be taken in the current working directory into the target directory instead. This is similar to options offered by some other similar tools, such as the -C option in "make". The new option is only accepted at the start of the command line (before the subcommand) as a way to reflect that it is a global command (not specific to a particular subcommand) and that it takes effect _before_ executing the subcommand. This also means it'll be forced to appear before any other command-specific arguments that take file paths, which hopefully communicates that those other arguments are interpreted relative to the overridden path. As a measure of pragmatism for existing uses, the path.cwd object in the Terraform language will continue to return the _original_ working directory (ignoring -chdir), in case that is important in some exceptional workflows. The path.root object gives the root module directory, which will always match the overriden working directory unless the user simultaneously uses one of the legacy directory override arguments, which is not a pattern we intend to support in the long run. As a first step down the deprecation path, this commit adjusts the documentation to de-emphasize the inconsistent old command line arguments, including specific guidance on what to use instead for the main three workflow commands, but all of those options remain supported in the same way as they were before. In a later commit we'll make those arguments produce a visible deprecation warning in Terraform's output, and then in an even later commit we'll remove them entirely so that -chdir is the single supported way to run Terraform from a directory other than the one containing the root module configuration.
2020-09-02 00:45:12 +02:00
Usage: `terraform console [options]`
2016-11-14 07:57:28 +01:00
This command provides an interactive command-line console for evaluating and
experimenting with [expressions](/docs/language/expressions/index.html).
This is useful for testing interpolations before using them in configurations,
and for interacting with any values currently saved in
[state](/docs/language/state/index.html).
2016-11-14 07:57:28 +01:00
If the current state is empty or has not yet been created, the console can be
used to experiment with the expression syntax and
[built-in functions](/docs/language/functions/index.html).
2016-11-14 07:57:28 +01:00
You can close the console with the `exit` command or by pressing Control-C
2016-11-17 10:23:50 +01:00
or Control-D.
command: Reorganize docs of the local backend's legacy CLI options We have these funny extra options that date back to before Terraform even had remote state, which we've preserved along the way by most recently incorporating them as special-case overrides for the local backend. The documentation we had for these has grown less accurate over time as the details have shifted, and was in many cases missing the requisite caveats that they are only for the local backend and that backend configuration is the modern, preferred way to deal with the use-cases they were intended for. We always have a bit of a tension with this sort of legacy option because we want to keep them documented just enough to be useful to someone who finds an existing script/etc using them and wants to know what they do, but not to take up so much space that they might distract users from finding the modern alternative they should consider instead. As a compromise in that vein here I've created a new section about these options under the local backend documentation, which then gives us the space to go into some detail about the various behaviors and interactions and also to discuss their history and our recommended alternatives. I then simplified all of the other mentions of these in command documentation to just link to or refer to the local backend documentation. My hope then is that folks who need to know what these do can still find the docs, but that information can be kept out of the direct path of new users so they can focus on learning about remote backends instead. This is certainly not the most ideal thing ever, but it seemed like the best compromise between the competing priorities I described above.
2021-03-25 00:17:03 +01:00
For configurations using
[the `local` backend](/docs/language/settings/backends/local.html) only,
`terraform console` accepts the legacy command line option
[`-state`](/docs/language/settings/backends/local.html#command-line-arguments).
2016-11-14 07:57:28 +01:00
## Scripting
The `terraform console` command can be used in non-interactive scripts
by piping newline-separated commands to it. Only the output from the
final command is printed unless an error occurs earlier.
2016-11-14 07:57:28 +01:00
For example:
2016-11-14 07:57:28 +01:00
```shell
$ echo 'split(",", "foo,bar,baz")' | terraform console
tolist([
"foo",
"bar",
"baz",
])
2016-11-14 07:57:28 +01:00
```
## Remote State
If [remote state](/docs/language/state/remote.html) is used by the current backend,
Terraform will read the state for the current workspace from the backend
before evaluating any expressions.
## Examples
The `terraform console` command will read the Terraform configuration in the
current working directory and the Terraform state file from the configured
backend so that interpolations can be tested against both the values in the
configuration and the state file.
With the following `main.tf`:
```hcl
variable "apps" {
type = map(any)
default = {
"foo" = {
"region" = "us-east-1",
},
"bar" = {
"region" = "eu-west-1",
},
"baz" = {
"region" = "ap-south-1",
},
}
}
resource "random_pet" "example" {
for_each = var.apps
}
```
Executing `terraform console` will drop you into an interactive shell where you
can test interpolations to:
Print a value from a map:
```
> var.apps.foo
{
"region" = "us-east-1"
}
```
Filter a map based on a specific value:
```
> { for key, value in var.apps : key => value if value.region == "us-east-1" }
{
"foo" = {
"region" = "us-east-1"
}
}
```
Check if certain values may not be known until apply:
```
> random_pet.example
(known after apply)
```
Test various functions:
```
> cidrnetmask("172.16.0.0/12")
"255.240.0.0"
```