A closer look at some useful IBM Cloud CLI environmental variables.

In some of my past IBM Cloud blogs, I showed you how to interact with IBM Cloud services from the command line. Today, I want to share some tips and tricks for the IBM Cloud CLI (command line interface), the ibmcloud command. Many of you work with that command, but have you ever looked into its help option and its environment variables? Here is a quick look at those variables and how to put them to good use:

IBM Cloud CLI environment variables

When I look up help on the root of the ibmcloud command, the output is something like this (with the list of commands cut away for readability):

$ ibmcloud --help
NAME:
  ibmcloud - A command line tool to interact with IBM Cloud
  Find more information at: https://ibm.biz/cli-docs

USAGE:
  [environment variables] ibmcloud [global options] command [arguments...] [command options]

...

Enter 'ibmcloud help [command]' for more information about a command.

ENVIRONMENT VARIABLES:
  IBMCLOUD_COLOR=false                     Do not colorize output
  IBMCLOUD_VERSION_CHECK=false             Do not check latest version for update
  IBMCLOUD_HTTP_TIMEOUT=5                  A time limit for HTTP requests
  IBMCLOUD_API_KEY=api_key_value           API Key used for login
  IBMCLOUD_TRACE=true                      Print API request diagnostics to stdout
  IBMCLOUD_TRACE=path/to/trace.log         Append API request diagnostics to a log file
  IBMCLOUD_HOME=path/to/dir                Path to config directory

GLOBAL OPTIONS:
  --version, -v                      Print the version
  --help, -h                         Show help

At the bottom of the output is a section on environment variables. In the following, I am going to briefly describe each of them and how I utilize them in my work. In your shell, you set those environment variables by a VARIABLE_NAME=VALUE pair directly in front of the command, or by using export VARIABLE_NAME=VALUE as a separate command before executing the actual shell command. 

• IBMCLOUD_COLOR: Setting and unsetting IBMCLOUD_COLOR to true or false allows you to control colorized output. Its usage and impact is shown on the screenshot at the top. The default is colorized CLI output.
• IBMCLOUD_VERSION_CHECK: This controls the regular versioning check for the CLI tool. Based on my observation the default is true.
• IBMCLOUD_API_KEY: Something helpful for simplification and testing is to utilize IBMCLOUD_API_KEY. The command ibmcloud login allows you to authenticate via an API key. That key can be specified directly as value or by referencing the name of the file containing the key via @filename. See the screenshot below for an example: 

  Authenticate to IBM Cloud using an API key.

• IBMCLOUD_TRACE: Utilize IBMCLOUD_TRACE to investigate how CLI commands are executed. By default, it is off. When enabled, it prints many useful details to the standard output (your terminal) or to the specified file. I often use it to look into how the CLI commands interact with the IBM Cloud platform and service APIs. The following screenshot shows how to enable tracing for just the executed command: 

  Tracing an ibmcloud command.

• IBMCLOUD_HOME: Last, but not least, IBMCLOUD_HOME is great for testing again. The ibmcloud command reads and writes its session metadata from/to the specified path. As I pointed out in this Stack Overflow answer, you could use it to work with multiple accounts or multiple sessions at the same time. This is great for automated, parallel testing or working with different accounts at the same time. Have a different directory for each and you are good to go.

Conclusions

By adapting your IBM Cloud CLI environment through environment variables, you can get more out of it. Use the capabilities to simplify API key-based login, to have multiple different CLI sessions in parallel or to investigate code flow. If you would like to use an on-demand CLI environment, I recommend experimenting with the IBM Cloud Shell.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.