When the Shell Says No

You will meet these two failures often in your first weeks at a terminal. Both look alarming and both mean something narrow and fixable.

“command not found”

pythno report.py

bash: pythno: command not found

The shell looked for a program called pythno, did not find one, and stopped. It never got as far as your file. report.py in that line was never even considered.

Read the message literally: it names the thing it could not find. Almost always that is a typo. Occasionally it means the program genuinely is not installed, which is Chapter 4’s problem, not this one.

“No such file or directory”

python data/report.py

python: can't open file '/workspace/data/report.py': [Errno 2] No such file or directory

This one is different in an important way: the shell found python perfectly well and ran it. Python started, went looking for the file you named, and could not find it.

Notice that the message contains an absolute path, /workspace/data/report.py, even though you typed a relative one. That path is a useful clue: Python is telling you exactly where it looked. Compare it with pwd to check whether you named the right file from the wrong directory.

Tell setup failures from exceptions in your code

The first failure came from Bash: it could not find the command. The second came from the Python interpreter: Bash started Python, but Python could not open the requested script. Both stopped before the first line of report.py ran.

An exception inside your program looks different. Python shows a traceback with files and line numbers, ending in the exception type:

Traceback (most recent call last):
  File "/workspace/report.py", line 3, in <module>
    print(f"You have read {len(boks)} books.")
                               ^^^^
NameError: name 'boks' is not defined

You already know how to read that from Fundamentals I. The new skill is deciding which layer to inspect. For command not found, inspect the command name. For can't open file, inspect the script path and working directory. For this NameError traceback, inspect the named line in your code.

Do not turn “no traceback” into a universal rule. Later in this course your own command-line programs will deliberately report some expected failures without one. Here, the command name, path, and traceback together distinguish these three examples.

That is the command line, enough of it. You can find out where you are, see what is there, move somewhere else, make and move files, run your own programs, and locate the layer responsible for these common failures.

Enough of it is the operative phrase. This chapter taught the commands Python needs from you and stopped there. If you want the rest of the toolkit, cp and rm and rmdir among them, Computer Fundamentals has a chapter on it:

The next chapter gives your programs somewhere of their own to live.

If an error message leaves you unsure where it came from, paste it to Monty and ask: “Did the shell find the command, did Python find the script, and did my code start? What in the message tells us?” Learning to locate the failing layer is the skill; asking a few times is how you get there.