Docs Beginners Workspace repo
Docs menu

Linux & Terminal Foundations

The concise Racerbot terminal cheat sheet: exactly the shell skills the team's Linux terminal skills assessment tests, plus a short list of external lessons worth your time.

This is not a Linux course. It is the cheat sheet for the terminal skills the team actually uses - and precisely what the Linux terminal skills assessment (Stage 2 Tech, Module 5) tests. Work through it once on your own machine (or inside your workspace container), keep it open while you practise, and do the drills. When every drill feels easy, you are ready for the assessment.

The mental model

  • The terminal is a text conversation with the computer: you type a command, it prints a result.
  • You are always somewhere: a working directory. pwd prints it, cd moves, ls lists what is here.
  • Commands are programs. command --help or man command tells you what one does.
  • Paths are absolute (/racerbot_ws/src) or relative to where you are (src). .. means “up one level”, ~ means your home directory, . means “here”.
  • Tab completion is the single biggest speedup: type the start of a path or command, press Tab.

Moving around and looking at things

pwd                  # where am I
ls -la               # list everything, with details
cd /racerbot_ws/src  # go somewhere
cd ..                # back up one level
cat file.txt         # print a whole file
less longfile.log    # page through a big file (q to quit, / to search)
head -50 app.log     # first 50 lines
tail -f app.log      # follow a log live (Ctrl-C to stop)

Drill: from anywhere, get to /racerbot_ws/src, list it, read a file with less, search inside it with /, quit, and get back home with cd ~.

Reading docs and finding things

The assessment has you read real documentation and real logs to find things.

man grep             # the manual (q to quit)
glow README.md       # renders markdown docs nicely (installed on team machines)
grep "error" app.log        # lines in app.log containing "error"
grep -rn "deadman" .        # search every file under here, with line numbers
grep -i "fault" app.log     # case-insensitive
find . -name "*.yaml"       # files by name

Drill: in a log file, find the line that mentions a fault with grep, then open the file at that spot in less to read the context around it. Hidden-file hunting: ls -a shows files starting with ..

Editing files

The team default editor is micro (installed on team machines); nano works the same way and exists everywhere.

micro config.yaml    # edit, Ctrl-S save, Ctrl-Q quit
nano config.yaml     # same idea: Ctrl-O save, Ctrl-X quit

Drill: open a config file, change one value, save, exit, and cat the file to prove the change stuck.

Permissions and running things

ls -l run.sh          # look at the permission bits
chmod +x run.sh       # make a script executable
./run.sh              # run it (the ./ means "in this directory")
source ./setup.sh     # run it IN your current shell (env changes stick)
. ./setup.sh          # same thing, shorter
./run.sh --map levine # arguments: the script reads them

The difference between ./run.sh and source ./run.sh matters constantly on this team: ./ starts a fresh shell that vanishes when it ends; source changes your current shell - which is why ROS 2 environment files (setup.bash) must be sourced, not executed.

Drill: write a three-line script that prints an argument, chmod +x it, run it with an argument, then source it and notice what happens to your shell’s variables.

tmux: terminals inside terminals

Remote sessions die when your connection does. tmux keeps things running on the machine and lets you split one connection into many terminals.

tmux                  # start a session
# inside tmux, the prefix is Ctrl-b, then:
#   c  new window      d  detach (everything keeps running)
#   n  next window     "  split top/bottom    %  split left/right
tmux attach           # reattach later (tmux a works too)
tmux ls               # list sessions

Drill: start tmux, run something long (e.g. ros2 topic hz /scan or tail -f a log), detach with Ctrl-b d, reattach with tmux attach, and stop the process cleanly with Ctrl-C. Ctrl-C is the safe stop for almost everything you will run; never kill -9 something on a car unless a lead tells you.

SSH: reaching other machines

ssh user@host         # log into another machine
exit                  # leave (your remote programs die unless they run in tmux)

On the team you SSH into the cars and the pit PC. Rule of thumb: land, start tmux first, then work - a dropped connection no longer kills your build.

Writing the short report

The assessment ends with a brief report: what you found, what you changed, how you verified. On a terminal that means: the grep line that located the fault, the config line you edited, and the command that proved the fix. Practice writing three sentences like that for each drill above - it is the same muscle as a good Discord post to your lead.

External lessons worth your time

Picked, not exhaustive:

Skip building a bigger study plan than that. The assessment tests fluency with the specific skills on this page, not Linux breadth.

Sources