Linux system errors
Linux 127 Command Not Found
Reviewed for reference consistency: April 11, 2026
Command Not Found — the specified command or file could not be located
What 127 Means
The 127 error on the Linux system errors indicates command not found — the specified command or file could not be located. This typically occurs due to typo in the command name.
Exit code 127 is returned by the shell when it cannot find the executable file in any of the directories listed in the PATH variable or at the absolute path provided.
How to fix 127
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Confirm the command can be found
Use the shell's command lookup to see whether the name resolves in the current environment.
command -v gitInspect the active PATH
A command may work interactively but fail in cron, CI, or service environments because PATH is shorter there.
printf '%s\n' "$PATH"Use an explicit local path
If the executable is in the current directory, call it with a relative path so the shell does not search PATH.
./script.shCheck the script interpreter line
A file can exist and still return 127 if its shebang points to an interpreter path that is not present on the system.
head -n 1 ./script.sh
Technical Background
Exit code 127 is generated by the shell when it searches through all directories in your $PATH variable and cannot find an executable file with the name you provided.
This is one of the most common errors in automated environments (like CI/CD or Cron jobs) where the $PATH environment variable might be limited or different from your interactive shell session.
Common Causes
- Typo in the command name
- The command is not installed on the system
- The directory containing the command is not in the PATH environment variable
- A script has an invalid shebang line pointing to a non-existent interpreter
- Windows line endings (CRLF) in a script causing the shell to search for an interpreter with a carriage return
Typical Scenarios
- Typing 'gitt' instead of 'git'
- Running a locally installed binary without providing the './' prefix
- A cron job fails because it runs with a minimal PATH that excludes /usr/local/bin
- Executing a shell script transferred from Windows that retains CRLF line endings
What to Know
Checking the spelling of the command and verifying its location within the current $PATH variable are the primary diagnostic actions. Use of absolute paths in automated environments ensures consistent execution regardless of environment state.
Frequently Asked Questions
Common questions about Linux 127 error
The PATH environment variable might be configured differently across different shell sessions, users, or automated environments like cron jobs.
Yes. If you attempt to execute a script that starts with a shebang (e.g., #!/bin/node) and that specific interpreter does not exist on the system, the shell will report command not found.
When a script is saved with Windows line endings (CRLF), the Linux shell interprets the carriage return as part of the interpreter's name (like bash\r). Since no such file exists, it returns a 127.