Skip to content
Latchkey

env and printenv: Inspect the Environment in CI

env prints the current environment variables and can launch a command with variables added, removed, or cleared, which is essential for debugging CI configuration.

Most "works locally, fails in CI" bugs are environment differences. env shows exactly what variables the step sees and lets you reproduce or strip the environment to isolate the cause.

What it does

env with no arguments prints every exported environment variable. Given NAME=value cmd it runs cmd with that variable set; -u NAME removes one; -i starts from an empty environment. printenv is the simpler read-only sibling for printing one or all variables.

Common usage

Terminal
env | sort                       # all variables, sorted
printenv PATH                    # one variable
env -i PATH=/usr/bin ./script    # run with a clean, minimal env
env DEBUG=1 NODE_ENV=test npm test

Options

Form / flagWhat it does
envPrint all environment variables
env NAME=val cmdRun cmd with NAME set
-u NAMERun with NAME removed
-iStart from an empty environment
printenv [NAME]Print all, or one variable
-0NUL-separate output (safe for newlines in values)

In CI

Print env | sort early to confirm a variable is actually set, but remember most CI systems mask known secret values in logs, so a secret may show as ***; an empty value means it was never injected (often a typo in the variable name or a secret not exposed to forks). Reproduce a clean-environment bug with env -i to find which variable a command depends on.

Common errors in CI

A variable that is set in one step but empty in the next is normal: each CI step usually runs in a fresh shell, so exports do not persist (use the platform’s environment-file mechanism instead). "env: ‘node’: No such file or directory" from a shebang like #!/usr/bin/env node means node is not on PATH for that step. Secrets printed as *** are masked, not missing.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →