Overview

This article will explain the nuances in how shell commands for your job is run within the CircleCI execution environment.
This article aims to demystify why certain commands may not work, or see different results when compared to running on a local machine or within a SSH session.

CircleCI shell is non-interactive

By default, CircleCI runs your steps' commands in non-interactive shell sessions.
Jobs running shell commands that require interaction (e.g., prompts) will thus timeout eventually due to the "waiting" command.

This can be an issue if you are running commands that returns outputs with a pager (e.g., `git log`
This will require interaction on the prompt to scroll through the output.

In this case, you can use `--no-pager` to disable pagination (and thus interaction).

# see most recent 5 commits, with no pagination
git --no-pager log -n 5

SSH debug sessions will be interactive

When using the SSH debug feature, note that you will be running shell commands in interactive mode. In other words, you will be in an interactive shell session.

This means, your SSH session may load up certain startup files from the execution environment (e.g., ~/.bashrc file).

For example, if using a Docker executor job, the Docker image may come up with a ~/.bashrc file that will be loaded for interactive sessions (SSH), but not for non-interactive sessions (within the CircleCI job execution).

Each step in a CircleCI job is its own shell

Note that CircleCI runs each step of a job in its own separate shell session.
To ensure you pass certain settings over to the next step, you can leverage the $BASH_ENV file.
See our guide on the $BASH_ENV file here.

Additional Resources: 

• Interactive and non-interactive shells and scripts
• .bashrc VS .bash_profile
• Debug with SSH