Linux Basics and AI Code Review
The first half is the Linux command line, which is what essentially every server and computing cluster runs on. The second half is code review — no writing, just finding what is wrong with someone else's code.
Contents
What this session is for
- Move around a filesystem, read files and search from the command line
- Review code with
ruffand with a debugger - Find all four categories of problem in AI-generated code, unaided
- Write an adequate AI usage declaration
Part one: the Linux command line
Why bother
The code you write will very likely run on a server with no graphical interface. Computing clusters, cloud instances, CI pipelines — the command line is all there is.
And plenty of tools are command-line tools to begin with: installing packages, running tests, reading logs, managing versions.
Getting to a Linux shell
| Your system | What to do |
|---|---|
| macOS | Use Terminal. macOS is Unix, and almost everything below works as written |
| Windows | Install WSL (Windows Subsystem for Linux): open PowerShell as administrator, run wsl --install, reboot, and you have a real Ubuntu |
| Linux | You are already there |
Moving around and looking
pwd # where am I
ls # what is here
ls -l # details: permissions, size, modified time
ls -a # including hidden files (those starting with .)
ls -lh # sizes in KB/MB
cd /path/to/dir # go somewhere
cd .. # up one level
cd ~ # home
cd - # back to the previous directory
Working with files
mkdir mydir # create a directory
mkdir -p a/b/c # create several levels at once
touch file.txt # create an empty file
cp a.txt b.txt # copy
cp -r dir1 dir2 # copy a whole directory
mv a.txt b.txt # rename or move
rm file.txt # delete a file
rm -r dir # delete a directory
Reading files
cat file.txt # print the whole thing (fine for small files)
head file.txt # first 10 lines
head -n 20 file.txt # first 20
tail file.txt # last 10 lines
tail -f log.txt # follow new output as it arrives (for logs)
less file.txt # page through it; q to quit, / to search
wc -l file.txt # count lines
Searching
grep "error" log.txt # lines containing error
grep -i "error" log.txt # case-insensitively
grep -n "error" log.txt # with line numbers
grep -r "TODO" . # recursively from here
find . -name "*.py" # every .py file
find . -name "*.py" -size +10k # and larger than 10KB
Pipes: chaining commands
| feeds one command’s output into the next. This is where the command line earns its keep.
ls -l | wc -l # how many files are in this directory
cat data.txt | grep "2026" | wc -l # how many lines mention 2026
ps aux | grep python # which python processes are running
history | grep git # what git commands did I run
Running Python
python3 hello.py # run a script
python3 -c "print(2**10)" # run one statement
python3 -m pip install ruff # install a package (this form avoids the wrong interpreter)
python3 -m pytest # run tests (L11 uses this)
A few more worth knowing
man ls # the manual for a command; q to quit
which python3 # which file this command actually is
echo $PATH # inspect an environment variable
chmod +x script.sh # make a file executable
df -h # remaining disk space
top # what is using the CPU; q to quit
Part two: AI code review
8-1 Command-line warm-up
Do this in your Linux environment (or macOS Terminal) and record every command and its output in your submission notes:
- Create a directory
cs1602/lab08under your home directory - Go into it and create three files:
a.py,b.py,c.txt - List them with
ls -land paste the output - Put
print("hello")ina.pyand run it withpython3 a.py - With a single command, count the
.pyfiles in your Lab 1–7 directory - Use
grepto find every occurrence ofTODOorprint(in your own code
8-2 Let ruff review your own code
python3 -m pip install ruff
ruff check .
Run it over everything from Labs 1 to 7. Answer in your submission notes:
- How many problems did it report?
- Which three categories came up most?
- Pick three you do not understand, find out why the rule exists, and write one sentence on each
8-3 Review four snippets
Each snippet below has exactly one problem. For each, write in your notes:
- what the problem is (which of L8’s categories)
- how you found it (by reading? by running? by testing?)
- a corrected version
# A
def second_largest(nums: list[int]) -> int:
s = sorted(nums, reverse=True)
return s[1]
# B
def title_case(s: str) -> str:
return s.capitalize_words()
# C
def has_duplicate(items: list[int]) -> bool:
for i in range(len(items)):
for j in range(len(items)):
if i != j and items[i] == items[j]:
return True
return False
# D
def count_chars(s):
d = {}
for i in range(len(s)):
c = s[i]
if c in d:
d[c] = d[c] + 1
else:
d[c] = 1
return d
8-4 Have an AI write a function, then take it apart
This problem requires you to use an AI for the first step.
- Ask an AI to write
is_valid_ipv4(s: str) -> bool, deciding whether a string is a valid IPv4 address - Do not look at its code yet. Write at least eight test cases of your own, including:
- at least 3 valid addresses
- at least 5 invalid ones (consider: wrong number of parts? above 255? leading zeros? empty string? spaces? negatives?)
- Run your cases against it
- Record how many passed and where it failed
- If it failed, fix it yourself first, then ask the AI why it missed that case
Attach to your notes: your test cases, the AI’s original code, the results, and your fix.
8-5 Step through recursion with a debugger
Using VS Code’s debugger on your hanoi() or factorial() from L7:
- Set a breakpoint on the recursive call
- Press F5, then step in with F11
- Watch the call stack panel on the left, and take a screenshot at the third level of recursion
- Answer in your notes: what does the call stack panel show, and how does it correspond to the indented prints you used in L7?
8-6 Write an AI usage declaration
Write one covering your work on this whole lab. Follow the example in L8 and include all three elements: what you used, what it produced, how you verified it.
If you used no AI at all this week, write “no AI used” and say why — that is an equally acceptable declaration.
Before you submit
- All six steps of 8-1 recorded with commands and output
- 8-2 identifies three rules you did not understand and explains them
- 8-3 answers “how you found it” for all four, and not all four say “by reading”
- 8-4’s test cases were written before looking at the code, and there are at least eight
- 8-5 includes a screenshot of the call stack panel
- 8-6 declaration written
- Solo project A submitted (due this Sunday, Level 0)