Images are reused AI-generated editorial illustrations, not documentary photographs or verified product screenshots.
Identify your Linux shell by separating the active process from the account's configured login shell. Environment variables can provide clues, but a single variable is not always authoritative about the shell currently interpreting commands.
Identify your Linux shell and the question to answer
The account's configured login shell, the terminal application's selected command and the current shell process may differ. A user can start Bash from another shell or launch a terminal with a custom command. Decide whether you need account configuration or the active interpreter.
Use multiple read-only indicators
In Bash, BASH_VERSION confirms a Bash-specific context and $0 can describe invocation. Process inspection such as ps for the relevant process can help, but options and process identifiers vary across platforms and subshell contexts. Treat SHELL as an account or environment clue, not conclusive proof.
Match instructions to the actual environment
Once the current interpreter is understood, use its syntax and manual. A command working in Bash may differ in another shell. Do not change the account's login shell just to run one tutorial; explicitly choosing the required interpreter can be a smaller, clearer action.
A practical checklist
- Separate login default from current process.
- Check more than one read-only indicator.
- Account for nested shells and subshells.
- Use the matching shell's syntax.
- Avoid changing account defaults unnecessarily.
Worked example
Illustrative example: an account's SHELL value names one shell, but the user has started Bash inside it. BASH_VERSION and the process context identify the active Bash session. The user follows Bash instructions without claiming the original login default has changed.
Common questions
Does SHELL always identify the current interpreter? No. Does the terminal application itself equal the shell? No; it hosts the process. Are all ps flags identical across systems? No; consult the local implementation when checking processes.
What to do next
Record the required interpreter in project instructions. Use read-only inspection first and make configuration changes only when the actual workflow requires them.