Linux troubleshooting: when 'command not found' made me revisit PATH and sudo su

Anyone working in the Linux terminal regularly has experienced this situation: you try running a system utility, get a stubborn command not found error, tweak your environment variables, reload the shell, and… the error persists unchanged.

Recently, I went through this classic environment debugging process while trying to run a binary named mimo as root. Isolating the issue served as a great practical reminder of how Bash initializes login profiles, how $PATH precedence works, the nuances of the su command, and effective disk search strategies.

The starting point and the stubborn error#

The original goal was ensuring root's $PATH monitored standard administrative directories:

• /usr/local/sbin
• /usr/local/bin
• /usr/bin

When checking for the mimo executable using which, the utility reported nothing:

[root@hackerpc /]# which mimo
which: no mimo in (/usr/local/sbin:/usr/local/bin:/usr/bin)

Even after editing /root/.bashrc and applying it with source, running the binary still failed:

[root@hackerpc /]# mimo
bash: mimo: command not found

[root@hackerpc /]# source /root/.bashrc
[root@hackerpc /]# mimo
bash: mimo: command not found

There was an obvious disconnect between expected shell behavior and the active session environment.

Where things fail: 3 critical inspection points#

Reviewing the terminal workflow revealed three common traps:

1. The sudo su trap without the login dash (-)#

Switching to root by simply running sudo su preserves much of the unprivileged user's environment variables. Bash does not launch a clean root login session, bypassing the default loading sequence for files like /root/.bash_profile or /root/.bashrc.

The correct approach: Always use sudo su - (or sudo -i). The trailing hyphen forces Bash to launch a full login shell, clearing stale environment state and parsing root's native dotfiles.

2. Unsaved buffer changes in the vi editor#

When editing /root/.bashrc quickly in vi, pressing Ctrl + C aborts the insertion mode without saving changes to disk. To write changes persistently, press Esc to return to command mode, followed by :wq and Enter.

3. Proper $PATH syntax and directory precedence#

To ensure trusted system directories take priority without discarding existing paths, the export directive should follow:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:$PATH

Security note: Placing trusted system paths before inherited $PATH strings prevents root from accidentally executing arbitrary binaries placed in secondary directories.

Applying the environment fix#

To normalize root's shell profile:

1. Open root's configuration:

vi /root/.bashrc

1. Press i to enter insert mode, add the export line at the bottom, and save via Esc + :wq.

1. Reload variables in the active terminal:

source /root/.bashrc

1. Confirm the updated path:

echo $PATH

The definitive diagnosis: finding where the file actually lives#

After fixing $PATH and logging in cleanly with sudo su -, the error message updated to the standard shell format (-bash: mimo: command not found). This confirmed the environment was healthy, but the mimo binary did not exist in any of those monitored directories.

When $PATH is verified and a command still fails, the problem is no longer shell configuration; it is physical file location.

To scan the entire filesystem without permission errors cluttering output:

find / -name "mimo" 2>/dev/null

Action plan once the binary is located#

Once find outputs the exact file path, there are two practical resolutions:

Option a: create a symbolic link (recommended)#

If the application lives under /opt/mimo or a user home folder, create a symlink inside a directory already indexed by $PATH:

ln -s /path/found/mimo /usr/local/bin/mimo

Option b: check execution permissions#

If the binary is already inside a indexed folder but refuses to execute, ensure executable flags are set:

chmod +x /path/found/mimo

Conclusion#

Diagnosing missing command errors in Linux requires a structured checklist: verify login shell initiation (sudo su -), check dotfile persistence in /root/.bashrc, inspect $PATH precedence, and finally locate the physical binary on disk with proper execution flags.

See also

Infrastructure How to bypass the global email limit in cPanel and CloudLinux: resolving error XID psafa9

Infrastructure Fixing the `$'\r': command not found` error in Bash scripts with forensic diagnosis and pipeline-level prevention

Linux How to fix failed to change directory error in OpenCode and Linux CLI tools

This post is licensed under CC BY-NC.