Exercise: The Workshop's Machines

Get an inventor's machines running with ls -l and chmod, an environment variable and a folder added to PATH, keep the broken one switched off, answer seven questions about permissions, owners and commands, and let a check script tell you what's done.

Apprentice · Unix · Linux · Updated

Ada Wren has gone to the inventors' fair and left you her workshop. Every machine in it is a small program, and none of them works yet: the kettle-bot and the clock aren't allowed to run, the kettle-bot needs power from the environment, and the oil can only works when the shell finds it on your PATH. One machine, the broken toaster, must stay switched off. Ada left a work order with four jobs and seven questions. A check script looks at the workshop and your answers and tells you which jobs are done.

Before you start

You need a terminal: the Terminal app on a Mac, or Ubuntu on Linux or in WSL on Windows. The check runs with bats, a small program that runs checks written for bash. If bats --version doesn't print a version number yet, install it:

sudo apt install bats       # Ubuntu, and Ubuntu in WSL
brew install bats-core      # a Mac, with Homebrew

sudo asks for your password, the one you use to sign in; nothing shows on the screen while you type it. As sudo and Who Owns a File explained, installing software is one of the jobs that needs it.

Get the exercise code

Open this lesson's GitHub repository, github.com/ask-codey/exercise-bash-the-workshops-machines, also linked from the Exercise box beside the lesson. Click Code, then Download ZIP, and unzip it into your terminal-practice folder. Or clone it with Git.

On Windows, put it in your Ubuntu home folder (~/terminal-practice/), not in a Windows folder under /mnt/c: Windows folders don't keep Linux permissions, so chmod wouldn't change anything there.

The folder holds:

  • workshop/: Ada's machines (kettle-bot, clock, broken-toaster and tools/oilcan), her diary, and work-order.txt, the list of jobs.
  • answers.txt: seven questions, each with a numbered line for your answer.
  • check.bats: the check. You don't need to change it.

What to do

Open a terminal, cd into the exercise folder (the one with answers.txt in it), then cd workshop and read the work order with cat work-order.txt. Look at the machines with ls -l, and read each one with cat before you run it: they're all a few lines long.

  1. Let the kettle-bot and the clock run. Give each one run permission, as in Permissions: Read, Write and Run, and try them with ./.
  2. Keep the broken toaster off. It must still have no x when you're done. Name the files you change one at a time, so a chmod +x * doesn't switch the toaster on by accident.
  3. Oil the gears. The oil can in tools needs run permission too. Then add the tools folder to the end of your PATH, as in PATH: How a Command Is Found, and type oilcan. It works only when the shell finds it on your PATH.
  4. Answer the questions in answers.txt. Open it in nano (nano answers.txt), write each answer after its ), and save. The file starts like this:
# Example: what is the name of the file that holds Ada's jobs for you?
# 0) work-order.txt

# 1. Run the kettle-bot with the environment variable POWER set to on. What ticket does it print? (Such as TEA-00.)
1)

Check your work

From the exercise folder (not from inside workshop):

bats check.bats

At first most checks fail. That's expected: each job you finish turns its check into a ✓. A failing check names the job or question and gives a hint, for example The kettle-bot can't run yet: ls -l shows no x in its permissions. chmod +x adds it.

Hints

  • No power? The kettle-bot reads POWER from the environment. POWER=on ./kettle-bot hands it to one run; a plain POWER=on on its own line stays in your shell, where the kettle-bot can't see it (Environment Variables: export and env).
  • The full path of tools. PATH wants a full path. Go into tools and type pwd to see it, then add it with export PATH="$PATH: and that path. Keep the $PATH: at the start, or the line replaces your whole list.
  • The oil can stays shut? Typing ./oilcan or tools/oilcan runs it by its path, without searching. Type the name alone.
  • Numbers. Read each set of three letters in ls -l: r is 4, w is 2 and x is 1, so rw- is 6 and r-x is 5.
  • Owners. In ls -l, the owner is the first name after the permissions and the number.
  • Closed the window? Your PATH change is gone with it. Add the folder again before you type oilcan.

When you're done

Every check passes:

check.bats
 ✓ the workshop is still here
 ✓ the kettle-bot may run
 ✓ the clock may run
 ✓ the oil can may run
 ✓ the broken toaster still may not run
 ✓ 1) the kettle-bot's ticket
 ✓ 2) the oil can's code
 ✓ 3) the kettle-bot's permissions as a number
 ✓ 4) the number for a private file
 ✓ 5) who owns /etc/hosts
 ✓ 6) where bash lives
 ✓ 7) what kind of command cd is

12 tests, 0 failures

Now open a new terminal window and type oilcan. It's command not found again: your PATH change lived in the window you closed. Startup Files: .bashrc, .zshrc and source, in the next chapter, is where you make a change like that stay.

Submit your exercise

The exercise is how you finish this lesson. When your work is done, put it on GitHub in a repo of your own, then submit that repo's address here.

  1. On GitHub, click +, then New repository. Name it (for example exercise-bash-the-workshops-machines), choose Public, and click Create repository. Leave out the README: your folder already has one.

  2. In a terminal in your exercise folder (Ubuntu in WSL on Windows), send your work to your new repo. If you downloaded the ZIP:

    git init -b main
git add .
git commit -m "My solution"
git remote add origin https://github.com/your-name/exercise-bash-the-workshops-machines.git
git push -u origin main

    If you cloned the starter instead, point your copy at your own repo, then commit and push:

    git remote set-url origin https://github.com/your-name/exercise-bash-the-workshops-machines.git
git add .
git commit -m "My solution"
git push -u origin main

  3. Paste your repo's address, such as https://github.com/your-name/exercise-bash-the-workshops-machines, into Submit your exercise on this page. The site checks that the repo is public and holds your commits, and then the lesson is complete.

Changed something after you submitted? Push it, and submit again: your latest submission is the one that counts. Git keeps a file's run permission too, so your repo on GitHub shows which machines may run.

So what

A program that won't run, a setting a program can't see and a tool the shell can't find are the three problems behind most "it doesn't work" moments when you set up a new tool, and you fixed all three.

Key terms

Related