The Terminal Is Not Scary

Core path: 35 minutes

Why type commands when the computer already has buttons?

Because commands expose state that graphical interfaces sometimes hide.

You do not need thirty terminal commands this week. You need a small toolkit and one reliable mental model:

The terminal is an interface. The shell interprets commands. Those commands act on files, directories, programs, and operating-system resources.

That is enough to stop treating the terminal like a mysterious black screen from a movie.

Terminal and shell are not the same thing

The terminal is the interface where the session is displayed and where you type.

The shell is the command interpreter running inside that terminal session.

Examples of shells include:

PowerShell
Bash
Zsh

So this relationship is more accurate:

TERMINAL WINDOW
      ↓ carries input/output for
SHELL
      ↓ interprets commands and launches
PROGRAMS / FILE OPERATIONS / OS TOOLS

When you type:

python hello.py

the shell resolves the python command, passes hello.py as an argument, and launches the interpreter.

The terminal displays the result.

The first question: where am I?

A ridiculous number of beginner terminal problems come from forgetting the shell's current location.

Run:

pwd

pwd means print working directory.

The working directory is the location the shell currently treats as its starting point for relative paths.

If the result is something like:

/home/student/week02-project

then a command referring to:

main.py

normally looks for main.py relative to that directory.

The second question: what is here?

Run:

ls

Compare the output with the editor's Explorer.

If both are looking at the same project location, you should recognize the same files and folders.

But remember: the Explorer can remain visually focused on the whole project while your shell moves into a subdirectory.

The interfaces can show related information without sharing the same "current location" concept.

Move deliberately

Suppose this exists:

week02-project/
├── main.py
└── experiments/
    └── hello.py

From the project root:

cd experiments

Then:

pwd
ls

You should now be inside the experiments directory and see hello.py there.

Move back up:

cd ..

Check pwd again.

Do not assume navigation worked because you typed the command. Inspect the resulting state.

One command can change what another interface shows

Create a directory:

mkdir scratch

Then run:

ls

Watch the editor's Explorer.

The terminal did not create a folder "inside the terminal." The shell asked the operating system/filesystem to create a directory. The Explorer then shows that changed filesystem state.

Same system. Two interfaces.

Paths are instructions about location

From the project root:

python experiments/hello.py

means roughly:

Launch Python and give it the file named hello.py inside the experiments directory relative to where I am now.

From inside experiments/, this can refer to the same file:

python hello.py

Same file. Different relative path because your working directory changed.

This is why pwd is not a beginner command you graduate from. Experienced developers still check location when context matters.

Wrong directory, right file

Create hello.py in the project root:

print("hello from the root")

Create and enter a subdirectory:

mkdir experiments
cd experiments

Now run:

python hello.py

The command should fail because the shell is asking Python for hello.py relative to experiments/, and that file is back in the parent directory.

Do not edit hello.py.

Do not reinstall Python.

Inspect:

pwd
ls

You have at least two valid repairs.

Move back:

cd ..
python hello.py

or address the parent file from your current location when appropriate:

python ../hello.py

The failure was about location.

That diagnosis is much more useful than "Python can't find my code."

Commands have structure too

Look again at:

python hello.py

A simple way to read it:

python    → command/program to launch
hello.py  → argument passed to that program

Now compare:

mkdir experiments

mkdir        → command
experiments  → name/path argument

You will see this command + arguments pattern constantly in Git, package managers, testing tools, Docker, ROS, and Linux utilities later.

The commands change. The shape stays familiar.

Your Week 2 terminal toolkit

By the end of this week, be comfortable using these commands:

• pwd — answer Where am I?
• ls — answer What is here?
• cd foldername — move into a directory.
• cd .. — move to the parent directory.
• mkdir name — create a directory.
• touch file.py — create an empty file on Unix-like systems.
• cat file.py — print a text file to the terminal on Unix-like systems.
• python file.py — launch Python with a source file.
• man command — open the manual page for many Unix/Linux commands.

You do not need to memorize flags for twenty other commands yet.

Terminal lab: type the commands yourself

The terminal below is a safe simulation of a small Unix/Linux shell workspace. It does not run commands on the Robotnix server or your own computer. We use Unix-style commands here because Linux shows up again in Git, cybersecurity, robotics, ROS 2, servers, and development tooling.

Start by typing:

help

Then work through the commands one at a time. Do not paste the whole sequence at once.

1. Type pwd. Read the path. This is your current working directory.
2. Type ls. You should see README.txt.
3. Type mkdir practice.
4. Type ls again. What changed?
5. Type cd practice.
6. Type pwd. Confirm that the path now ends in /practice.
7. Type touch hello.py.
8. Type ls. Confirm that hello.py exists.
9. Type exactly:

echo 'print("Hello from Python")' > hello.py

That command writes one line of Python source into hello.py.

10. Type cat hello.py. Verify what is actually saved in the file.
11. Type python hello.py. You should see Hello from Python.
12. Type man ls. Read the short manual entry.
13. Try man mkdir, man pwd, and man python.
14. Type cd ...
15. Type pwd and ls one final time.

Robotnix shell practice
This behaves like a small Unix/Linux terminal lesson, but it is not a real operating-system shell.
Type 'help' to see the guided command sequence.

$ pwd
/home/student/python-lab

$ ls
README.txt

$ mkdir practice

$ cd practice

$ touch hello.py

$ echo 'print("Hello from Python")' > hello.py

$ cat hello.py
print("Hello from Python")

$ python hello.py
Hello from Python

$ man ls
LS(1)
NAME
    ls - list directory contents
EXAMPLE
    ls
TIP
    Use ls to answer: What files and folders are here?

What to notice

The important part is not the green text or the prompt. Track the state changes:

start in python-lab
→ create practice/
→ move into practice/
→ create hello.py
→ write source code into hello.py
→ inspect the saved source
→ ask Python to execute it
→ observe output

That is the same developer workflow you will use in larger projects later.

What about PowerShell or Windows?

Your school or home computer may use PowerShell, and some command names differ. That is okay. The learning target is the model: current directory, files, paths, commands, arguments, programs, and output. When a command differs across shells, read the tool's documentation instead of pretending every terminal is identical.

One last check

Before Lesson 4, prove you can explain—not merely type—this sequence:

1. identify a working directory with pwd;
2. list its contents;
3. create and enter a directory;
4. create and inspect a text/source file;
5. run a Python file;
6. return to the parent directory; and
7. explain what changed after each command.

If one of those steps fails, read the command, working directory, and path before touching the Python code.