CS1602Introduction to Computation
Lab 8Part 3 Problem Solving with AIAI Level 1

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.

Due:Homework 3 · Tue 17 Nov, 23:59
Contents

What this session is for

  • Move around a filesystem, read files and search from the command line
  • Review code with ruff and 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 systemWhat to do
macOSUse Terminal. macOS is Unix, and almost everything below works as written
WindowsInstall WSL (Windows Subsystem for Linux): open PowerShell as administrator, run wsl --install, reboot, and you have a real Ubuntu
LinuxYou 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:

  1. Create a directory cs1602/lab08 under your home directory
  2. Go into it and create three files: a.py, b.py, c.txt
  3. List them with ls -l and paste the output
  4. Put print("hello") in a.py and run it with python3 a.py
  5. With a single command, count the .py files in your Lab 1–7 directory
  6. Use grep to find every occurrence of TODO or print( 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:

  1. How many problems did it report?
  2. Which three categories came up most?
  3. 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.

  1. Ask an AI to write is_valid_ipv4(s: str) -> bool, deciding whether a string is a valid IPv4 address
  2. 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?)
  3. Run your cases against it
  4. Record how many passed and where it failed
  5. 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:

  1. Set a breakpoint on the recursive call
  2. Press F5, then step in with F11
  3. Watch the call stack panel on the left, and take a screenshot at the third level of recursion
  4. 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)