Introductory lab sessions

Introductory lab sessions
COMP10001: An introduction to Unix
Introductory lab sessions
Steve Pettifer, Toby Howard, Graham Gough and John Latham
Autumn 2017
School of Computer Science
University of Manchester
Contents
0
Getting started
4
0.1
Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
0.2
About these notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
0.2.1
Breakout boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
0.2.2
Styles and conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
0.3
The CS labs setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
0.4
Using Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
0.5
Reading your email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
0.6
Rebooting into Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
0.7
Getting started with Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
0.8
1
0.7.1
Connecting the Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
0.7.2
Changing your password . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
0.7.3
Network Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
0.7.4
Date and time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
0.7.5
Disabling the user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
0.7.6
Finishing off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Unix and Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
0.8.1
Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
0.8.2
Unix Origins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
0.8.3
Modern Unix Variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Getting started with Raspberry Pi
1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1.1
1.2
1.4
Using the Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Processes and the Unix Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.2.1
1.3
23
The process ‘family tree’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
File systems and files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.1
The Unix filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.3.2
Files in more detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
The Colossal Cave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.4.1
September 8, 2017
Installing Frotz, a Z-Machine Interpreter . . . . . . . . . . . . . . . . . . . 35
1
COMP10001
2
1.5
Quake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.6
RTFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.7
Shutting down your Pi safely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.8
What have you learned? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Using the Linux desktop in CS
41
2.1
Logging in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2
Reading email in terminal mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3
Browsing the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.1
Pipes and Redirects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4
X Windows and GNOME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.5
X Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.6
Window Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.7
Starting a graphical environment automatically . . . . . . . . . . . . . . . . . . . . 55
2.8
ARCADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.9
Text Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.10 Shell environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.11 Configuring Thunderbird . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.12 That’s all for now . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3
Pi power
3.1
The LXDE graphical environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2
Configure mutt again using scp and ssh . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.1
Emailing your tutor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.3
X Windows again . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.4
A Simple Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.4.1
3.5
4
62
A slightly more interesting web page . . . . . . . . . . . . . . . . . . . . . 70
Headless Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.5.1
Setting up Apache, a proper web server . . . . . . . . . . . . . . . . . . . . 73
3.5.2
Permissions, users and groups . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.5.3
Back to that webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.6
Shutting down gracefully . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.7
Finishing up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Blackboard Intro and command line skills
4.1
79
Getting started with Blackboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1.1
The COMP10120 course unit site . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1.2
Lab deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.3
Using discussion boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.4
Using wikis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2
COMP10001
4.1.5
4.2
Writing your reflective journal . . . . . . . . . . . . . . . . . . . . . . . . . 82
Reinforcing your command line skills . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2.1
Creating a directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.2
Copying, moving, and removing files . . . . . . . . . . . . . . . . . . . . . 85
4.2.3
Practice makes perfect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2.4
Wild cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.2.5
Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.2.6
Putting commands together . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.2.7
Making your own commands . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.2.8
Doing several things at a time: background running . . . . . . . . . . . . . 93
4.2.9
Printing text files: lpr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2.10 Time for a checkup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.2.11 Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.2.12 The end of the beginning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.3
5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Appendix
98
5.1
Directories in the Pi’s root filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2
A Map Of Colossal Cave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3
Basic HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.4
5.3.1
Basic page structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3.2
Page structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3.3
Hyperlinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Using USB sticks in Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3
Welcome Lab Session 0
Getting started
Contents
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
Welcome . . . . . . . . . . . . . . .
About these notes . . . . . . . . .
0.2.1 Breakout boxes . . . . . . .
0.2.2 Styles and conventions . . .
The CS labs setup . . . . . . . . .
Using Windows . . . . . . . . . . .
Reading your email . . . . . . . .
Rebooting into Linux . . . . . . .
Getting started with Raspberry Pi
0.7.1 Connecting the Pi . . . . . .
0.7.2 Changing your password .
0.7.3 Network Registration . . .
0.7.4 Date and time . . . . . . . .
0.7.5 Disabling the user interface
0.7.6 Finishing off . . . . . . . . .
Unix and Linux . . . . . . . . . . .
0.8.1 Operating Systems . . . . .
0.8.2 Unix Origins . . . . . . . . .
0.8.3 Modern Unix Variants . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
5
5
5
5
6
8
10
10
11
14
17
18
19
19
19
20
20
20
These notes are available online at
syllabus.cs.manchester.ac.uk/ugt/COMP10120/labscripts/intro0.pdf
We suggest you use the online version so that you can follow web links.
0.1
Welcome
Hello and welcome. In this first, introductory, lab we’re going to cover some of the basic things
you’ll need to know about the IT infrastructure here in the School of Computer Science, and
get your Raspberry Pi set up so that you can get going quickly in the next lab. Some of what
we tell you may well seem very obvious to you, and if that’s the case we ask you to be patient.
Some other things might not be so obvious...
September 8, 2017
4
Welcome
Getting started
In this and every lab there will be staff, consisting of academic staff and postgraduate students,
around to help you. If you’re stuck or find something that you really can’t understand, then
please ask for help; that’s what the lab staff are here for, don’t just sit there getting frustrated.
The postgraduate students are known as Teaching Assistants, or TAs for short.
0.2
0.2.1
About these notes
Breakout boxes
Scattered throughout the main text of these exercises there are information boxes of various
kinds:
Danger! The bomb icon explains problems and pitfalls, and how to
avoid them. It’s really important that you read these sections, or you
may regret it later.
Raspberry Pi Facts and Factoids. These sections explain useful but
non-essential things about the Raspberry Pi. If you’re pushed for time,
you can safely skip these boxes and perhaps come back to them another
time.
We digress. . . Boxes marked with this icon contain digressions and
facts that are hopefully interesting but are probably tangential to the
main flow of the exercise.
Stop here. . . Boxes marked with this icon contain checkpoint activities
that you should complete before proceeding further.
0.2.2
Styles and conventions
We’ll be using various typographic styles to indicate different things throughout these notes.
When we introduce new concepts, or use terms that have a different meaning in computer
science to their everyday use, they will appear like this, and will be explained in the nearby
text. Things that are either the input or output to commands will appear in this font. And
many words or phrases will have a little ‘w’ after them, meaning that if you click on the term
(if you’re reading the notes online) or type the phrase into Wikipedia (if you’re reading this
on paper), you should be taken to a sensible definition in case you want to learn more about
something that we’ve touched on here.
W
Where you see text in square brackets [LIKE THIS] it will mean that when you’re typing things
you should replace the text with something that the text describes; for example [NAME OF
THIS CITY], would become Manchester.
0.3
The CS labs setup
All the desktop PCs in the labs in the Kilburn building are ‘dual-boot’: they can be started up
running either Linux or Windows. This is for flexibility – the labs for most course units use
Linux, but some use Windows, and of course, outside the labs, you’re free to use whichever
5
Welcome
Getting started
Figure 1
The Windows7 Welcome screen.
you prefer for any aspect of your studies that does not require use of a particular operating
system. If you’re not familiar with Linux, don’t worry. We’ll be telling you a bit about it in this
lab, and you’ll be looking at it in much more detail in subsequent labs.
0.4
Using Windows
We’ll start with Windows, so the first thing we need to do is to make sure your PC is running
Windows. Have a look. If it is, and the screen looks like Figure 1, then you will not need to
reboot, but please read the next bit anyway, because at some point you may need to reboot
from Linux to Windows.
If your PC is currently in Linux, showing a black screen with a login prompt, you need to
reboot the PC. To do this, press ctrl, alt and delete.
This will probably cause strange messages to appear on the screen, disappear, and be replaced
by yet more strange messages. Now look at Figure 2: when you see something like that on the
screen press space you will need to respond. Meanwhile, be patient, watch it all happen, and
don’t worry what it all means.
After a while, everything should settle down and the screen will look like Figure 2; press space
now!
This is where you decide whether to start up Windows or Linux. If you do nothing when this
screen appears, the computer automatically boots into the default operating system after a fixed timeout
period. By pressing the space bar (any other key would have done) you have stopped this timeout
process.
Now use the up/down arrow keys on the keyboard to highlight the line reading Windows 7,
and press the enter key. After a short while, the Windows 7 welcome screen will appear,
6
Welcome
Getting started
Figure 2
The boot selection menu screen.
as shown in Figure 1. Now use ctrl-alt-del again as instructed and you should see the
Windows 7 login screen, as shown in Figure 3.
To log in to your personal account, type in your username (this is an 8-character name usually
starting with an ‘m’ that you were given at registration). Your password will be the one you
set at registration. If your password doesn’t work, or if you’ve forgotten it, you need to fix this
urgently. You can login on a machine running Windows, with the username register and
password register, then follow the instructions.
If you forget your password later on, you can also use one of the following methods:
• If you have access to a web browser, use the password recovery page at
https://iam.manchester.ac.uk/recover
• You can also contact the University IT helpdesk (opening hours are Monday to Friday
09:00 – to 17:00) by phone on 0161 306 5544, or dial 65544 from a University internal
phone; or you can visit a helpdesk either on the ground floor of the Kilburn Building
(Room G-96), in the Main Library (Building 55 on the Campus Map), or in the Alan
Gilbert Learning Commons (building 63).
• Remember, if you need help, ask!
Once you’re logged in, go to your My Manchester page in a web browser, at
https://my.manchester.ac.uk
You will have to authenticate again to access this page, which should look something like
Figure 4.
7
Welcome
Getting started
Figure 3
The Windows 7 login screen.
0.5
Reading your email
We use email extensively in the School, so it’s vitally important that you read your mail
regularly—we work on the assumption that you’ll be checking your School email at least once
a day (and probably much more often). On the top menu bar of your My Manchester page,
click the Mail icon next to ‘Search’ to access your email on the University’s Office 365 system,
which gives you 25GB of email storage space and an integrated calendar. You should see a
page looking something like Figure 5.
Have a look around for a few minutes and check what mail you’ve got. In particular, look for
one with ‘The Monday Mail’ in the Subject line. This is an important mail you’ll receive every
Monday (hence the name) throughout your 3 or 4 years with us in the School which tells you
what’s going on each week. Take a moment to read it now. You can always read the Monday
Mail, by the way, at the archive located at
studentnet.cs.manchester.ac.uk/ugt/mondaymail/
Office 365, like most modern email systems, supports the IMAP protocol – which means that
you can access your mail from any device that can run an IMAP mail client. Some examples of such clients are: Mozilla Thunderbird, Mac Mail, Outlook and mail apps on mobile
devices. No matter what client you use, you need to tell it the appropriate settings. The mechanism for finding these setting can be found in our CS student IT wiki, which is located on the
web at wiki.cs.manchester.ac.uk/index.php/StudentFAQ/IT. Look for the answer
to the question ’How do I configure my favourite IMAP mail client?’. This wiki provides help
about the IT infrastructure within the School; it is one of several School FAQ lists, which can
be found at wiki.cs.manchester.ac.uk/index.php/StudentFAQ. Please make use of
these valuable sources of information.
Once you’ve found the IMAP and mail server settings, use Office 365 to email this information
8
Welcome
Getting started
Figure 4
Your My Manchester page.
Figure 5
Your Office 365 email.
9
Welcome
Getting started
Figure 6
Restarting the PC.
to yourself, to your University account, which is usually of the form:
[email protected]
You should also write this IMAP and mail server information down somewhere you can find
it, as you will need it in a later lab when you may not have access to your email.
You’ll need this information later so please don’t delete this email after you’ve read it.
Finally, if you use an IMAP mail client on your phone or mobile device, you can configure it
to use the settings you’ve just found, and check that you can read and send email successfully.
It’s probably best to try this later as the mobile signal in the lab is not good.
That’s all on Windows for now, but of course you’re free to boot an available PC into Windows
and use it at any time unless you are in a lab that requires the use of Linux.
0.6
Rebooting into Linux
So let’s reboot the PC, and start it up in Linux. First, log out of Windows by selecting the
Windows icon in the bottom left of the screen and then Log off. Get back to the login screen,
click the small icon in the lower right of the screen (see Figure 6) and select Restart.
The system will shut down and after a while we’ll be back to the boot selection menu screen
we saw earlier in Figure 2. This time, press space immediately, then use the up/down arrow
keys to select EPS Linux (Scientific Linux). Linux will now start, and after a short while
you should see a black screen, with a white login prompt.
We won’t login to Linux at this stage, that can wait until a later lab. We would, however, like
you to read the rest of this document, which gives you some useful and interesting background
information about Linux. If you don’t have time to finish reading it in the lab, please make
sure you do so before the next lab session.
Before we move on to this reading we would like you to make a start in setting up your very
own Raspberry Pi computer. During this process there will be a period where you have to sit
and wait for something to happen; this will give you a good opportunity to read the background information about Linux.
0.7
Getting started with Raspberry Pi
You should by now have received all the bits you’ll need to assemble your Raspberry Pi.
The Raspberry Pi is an astonishing piece of hardware. Not because it is super-fast or superpowerful—it’s actually quite a slow computer by today’s standards—but because it is small,
cheap and needs very little energy to run. Its cheapness means you can experiment with it
10
Welcome
Getting started
Breakout 1: Why is it called a Pi?
The Raspberry Pi apparently got its name because (a) lots of other computer
systems have been named after fruit (you’ll know of Apple and Blackberry,
but in the past there has also been at least Apricot and Tangerine), and (b) the
Python language was one of the first things ported to run on it. The logo
was created by Paul Beech, and is based on Buckminsterfullerene , a spherical fullerene
molecule more commonly called a Buckyball. Its designer pointed out that a full buckyball
has 32 faces, but that only 11 are visible in the 2D logo; and that the Raspberry Pi has a
32-bit processor and an ARM11 on board.
W
W
The ARM processor, on which the Pi and the vast majority of the world’s other mobile
devices are based, was originally designed by a team led by Steve Furber , who is a Professor in this School.
W
safe in the knowledge that if you mess it up, lose it, or drop it into the canal, getting hold of a
replacement isn’t going to cost you much more than a text-book or a night out at the cinema.
Its small size and fairly modest power requirements mean that it can be put to use in lots of
applications where a regular-sized PC would be impractical. We hope this will encourage you
to experiment and explore, and to take risks playing with both its hardware and software that
you might be reluctant to do on your own computer or tablet, or simply can’t do with the
School’s lab machines.
In this lab session we start the process of setting up the Raspberry Pi and continue in the
next one to use it and get you familiar with the Pi, and with some of the basics of the Linux
operating system it uses. We’re going to be covering a lot of ground quite quickly, and it’s
important that you read these notes carefully and follow the instructions precisely for now.
As the lab sessions progress, the instructions will become much less prescriptive, and we’ll be
encouraging you to experiment and explore much more, and to find out things for yourself.
But for now, just follow our lead.
The most remarkable thing about the Pi is that, although it’s not the most powerful of computers, it is capable of running the same full Linux operating system as the machines that you’ll
be using in the labs for the duration of your studies, and which you’ll undoubtedly encounter
in your future careers. We’re actually going to be using slightly different flavours of Linux on
the Pi and the lab machines, but the differences are fairly minor—more on that later. Let’s get
started.
W
The Raspberry Pi itself is just the circuit board shown in Figure 7. Your kit contains a Pi
together with a case, SD card and power supply. If you want to replace the case with one in
a different style you’re welcome to do so (there are plenty available to buy online, and lots of
people have made their own unique ones just for the fun of it). The Pi is reasonably robust,
and you can use it without a case, but obviously it’s a bit more vulnerable if it’s not in a box of
some sort. Figure 8 shows the Pi’s circuit board from beneath, indicating where the micro SD
card gets inserted.
0.7.1
Connecting the Pi
It’s important that you connect the Pi up in exactly the order specified here—so even if you are
familiar with using a Pi, please don’t jump ahead and plug everything in at once (no harm will
11
Welcome
Getting started
Figure 7
An uncased Raspberry Pi 3. The numbered connectors are 1 HDMI output, 2 four USB
ports, 3 micro-USB power input, 4 stereo audio out, 5 General Purpose Input/Output
(GPIO), 6 Ethernet.
come to the Pi if you do, but this exercise relies on your following our instructions closely).
Refer to Figure 9, and then connect your Pi up like this:
• The monitors in the LF31 Lab are all fitted with an extra video lead for connecting up the
Pis. We try to standardise on blue cables for connecting to a Pi. Locate the HDMI lead
(labelled 1 in Figure 9), and plug this into the socket marked 1 on Figure 7.
• Next we’ll need to connect a keyboard and mouse. Identify the male and female USB
connectors marked 2 on Figure 9, and note that there is a red dot on each. Separate
the two connectors and plug the male end into one of the USB sockets (it doesn’t matter
which) on your Pi (marked with 2 on the Figure 7). Later, when you’ve finished this lab
(and every other time you connect your Pi) please make sure to reconnect the male and
female connectors to the PC as a courtesy to the next user. When you reconnect, be sure
to align the two dots marked on the male and female connectors, to prevent you forcing
them together the wrong way round and damaging them.
• Do not connect the power or network connectors at this stage!
Next, we need to insert the memory card that contains the Pi’s operating system, and on which
you’ll be storing your own files (note although this is a ‘memory card’, for the Raspberry Pi it’s
behaving like the ‘hard disk’ of a regular computer, not like the memory of a regular computer).
The card you’ve been given comes with a little caddy that allows it to be used as a full-sized
12
Welcome
Getting started
Figure 8
A Raspberry Pi 3 from below. The ports are numbered as in Figure 7, and 7 shows the
location of the micro SD (Secure Digital) memory card slot, and the correct orientation of the
card to insert into the Pi. The card is shown much larger than it is!
Figure 9
The cables for connecting your Pi.
(ethernet).
1 HDMI, 2 keyboard and mouse, and 3 network
13
Welcome
Getting started
Figure 10
The Input Selection menu on the monitor. This image of the Dell U2412M Monitor has been
reproduced with the kind permission of Dell. All rights reserved.
Secure Digital card, but for the Raspberry Pi Model 3 we just need the little micro SD card.
Carefully pop that out of its case and then refer to Figure 8 to see where it goes on the Pi’s
board. It should slide both in and out smoothly. Don’t force the card in or you might damage
it or the Pi – if you’re not sure, get some help.
Now we need to switch the input on the monitor from DisplayPort (which is the input used by
the PC) to DVI (the cable you’ve connected your Pi to is a HDMI to DVI cable). On the lowerright side of the monitor you will see 4 buttons – see Figure 10. Press any of them to bring
up the monitor’s menu. Now press the 3rd button down and navigate to the input selection
menu. Switch the Input to DVI-D and press the green ‘tick’ button.
Now you’re ready to power up the Pi. Plug your Pi power supply into the ’toblerone’ power
block behind the PC, and connect the 5v Micro USB cable (the same connector that you’ll
find on many phones and tablets) into the socket marked 3 on Figure 7. There is no power
switch on the Pi, so as soon as the power cable goes in, it will start to boot (this strange term is
explained in breakout box 3): the red LED immediately next to the power socket should light
up and stay on, and you’ll also notice that the other LED to its left (which indicates SD-card
activity) also flickers.
You should see a black screen with white text scrolling up the screen as the Pi boots. When
things settle down and the screen looks like Figure 11 you’re ready for the next task.
0.7.2
Changing your password
Now it’s time to change your password. This is very important, because shortly you’ll connect
to a network, and it’s not safe to do that while your Pi still has its default password set. On
the screen you will see a panel of tool icons on the top left. Click on the icon that looks like a
monitor screen. This runs a command line terminal that you can enter commands in. Don’t
worry at this stage exactly what the commands mean. Type:
sudo raspi-config
followed by the Return key. This will bring up the Pi configuration screen, as shown in Figure 12.
14
Welcome
Getting started
Figure 11
The Pi’s default graphical user interface – a window manager called LXDE.
Figure 12
The Raspberry Pi config tool. The highlight bar can be moved between the different controls
using the Tab key, or up and down in the menu using the arrow keys.
15
Welcome
Getting started
Breakout 2: Raspbian
Raspbian is a version of the Debian release of Linux, tuned for the Pi. If you
manage to corrupt the operating system, or just want to start from scratch,
then re-writing the SD card with a fresh image is reasonably straightforward:
simply reboot your Pi and press the Shift key when the initial splash screen
loads (you will need to be quick, as it only appears for a few seconds). This will present
you with a list of options. Ensure that Raspbian is selected and then click the Install icon
to re-write the SD card with a fresh image. This will erase all of the data on the Pi, so it’s
crucial that you make sure that you have a backup of anything important.
If you buy a new SD card, instructions on how to get hold of the files you’ll need,
and how to write them to the SD card on various operating systems are available at
www.raspberrypi.org/downloads. You might want to think about getting a larger
SD card in any case; the one we’ve given you is fine for the labwork we’ve set, but probably a bit on the small side for anything else. SD cards are widely available in shops and
online, and aren’t expensive. But you should check whether the specific card you’re going to buy is compatible with the Pi before parting with any money—differences in the
read/write speeds of some cards mean they don’t play nicely with the Pi.
Use the arrow keys to select ‘Change User Password’ and press Return. You’ll see another message – ‘You will now be asked to enter a new password for the pi user’– and select <OK> with
the Return key to get to the password entry screen, which says ‘Enter new UNIX password’.
Think of a password for your Pi which is:
• not the same as your University password
• easy for you to remember
• not easily guessable by someone else
and of course keep it secret, and type it in. Don’t worry about the password you’re typing not
appearing on the screen – that’s normal. Select <OK> if the password is changed successfully.
Back at the config window, tab to Finish and press Return.
16
Welcome
Getting started
Breakout 3: Booting
The phrase ‘booting’ to refer to the process of starting up some computer
system has become quite commonplace, but its origins are rather strange.
It’s thought to have first been used in early 19th Century America as a way
of describing an obviously impossible action such as to “pull oneself over a
fence by one’s bootstraps”. These days it is used to refer to any self-sustaining process
that is able to happen without external help.
So why is starting a computer a bootstrapping process? In order for you as a user to be
able to run a program, the computer needs an operating system. But in order to load
its operating system, it needs some instructions that tell it how to understand the file
system. And in order to load the instructions that tell it how to understand the file system
it needs to. . . well, you get the idea. In reality, most computers have a very small set of
instructions hardwired into them that begin the process of loading a slightly more complex
‘bootloader’, which then begins the process of loading the OS kernel and any modules
needed to interact with the hardware, and then starts loading services and features of
increasing sophistication that rely on the simpler ones loaded previously to function.
As an aside, you may want to consider this: if you need a text editor to write programs,
how did the first text editor (which is itself a program) get written?
DON’T FORGET YOUR PI PASSWORD. It is very important that you do not
forget this password; there’s no easy way to get back into your Pi without
resetting everything, and this is a time-consuming task.
Memory Loss. Although the Pi uses a fairly standard Unix operating system,
it’s probably not quite as secure as a normal desktop machine because of its
small size and easily-removable storage media. Once the Pi has booted from
the SD card, it’s about as secure as any other Linux machine, but because
the memory card is easily removable, it can trivially be connected to another
machine as a ‘removable media’ device; and at that point the host machine
can almost certainly see its contents, including any of the files you’ve created, because the filesystem itself isn’t encrypted. And because the Pi is
small and portable, it’s easier to lose it than a laptop or desktop machine; so,
be careful!
0.7.3
Network Registration
For security, the School has created a secure private Raspberry Pi network, which is separated
from the main University network and the internet, so you won’t be able to access the world
outside the Pi network until you register your Pi. Now that your Pi password isn’t the same as
the ‘out of the box’ Pi one, it’s safe to plug your Pi into the network. Locate the blue ethernet
cable poking out of the desk (labelled 3 on Figure 9) on page 13; plug that into the network
socket on your Pi ( 6 on Figure 7, page 12). Click the globe icon in the panel at the upper left of
the screen. The Chromium web browser should appear. Type google.co.uk into the address
bar and press enter, you should be redirected to the registration page shown in Figure 13. Enter
17
Welcome
Getting started
Figure 13
The NetReg registration page.
your University username (the 8-character one starting ‘m’) and your University password. If
the browser asks if you want to save the password, click never.
If you register successfully, the next page will ask you to shutdown your Pi. To do that, click
the top-left raspberry icon and on the drop-down select Shutdown, and on the pop-up pane
that appears, select Shutdown. Lots of cryptic messages will scroll down the screen, and the
Pi will shutdown, leaving just the red LED lit.
Now you need to wait for two minutes, for the network registration to take effect. So have a
two-minute break, and read a bit about Unix, further in this document.
After your break, restart the Pi. But how? There is no on-off switch! The only way to do this is
to very carefully pull out the micro-USB power plug and re-insert it. Be careful!
Your Pi should now boot up as before. Start the browser again, and check that you can reach
www.cs.manchester.ac.uk. If not, ask for help.
0.7.4
Date and time
The Pi has an internal clock, which can be set automatically by syncing it to an Internet time
server using the Network Time Protocol (NTP) . This behaviour isn’t enabled by default, so
we need to switch it on.
W
As you did before, from the panel of tool icons on the top left of the screen, click on the icon
that looks like a monitor screen to open a command line terminal. Issue the following two
commands, typing the Return key after each one.
sudo timedatectl set-timezone "Europe/London"
sudo timedatectl set-ntp true
Now issue the date command (again, followed by Return) to verify the time and date are now
correct:
date
18
Welcome
0.7.5
Getting started
Disabling the user interface
As you’ve seen, the Pi automatically starts a graphical user interface; as we need to be more
flexible, we will disable this behaviour. Once this is done your Pi will subsequently start with
a simple command line prompt.
In the terminal window where you started the clock syncing, bring up the Pi configuration
screen again by typing
sudo raspi-config
and when the configuration screen appears, use the arrow keys to select ‘Boot Options’, then
press Tab until <Select> is highlighted, then press Return. This will bring up another configuration screen. This time use the arrow keys to select the option ‘Text console, requiring user
to login’. Again use Tab until <OK> is highlighted, then press Return. At the next screen tab
to finish and press Return. The next screen will say ‘Would you like to reboot now?’. Tab to
<No> and press Return.
0.7.6
Finishing off
You should now be back in the command line Terminal, where you can stop the Pi by typing
sudo halt
followed by the Return key.
We’ll explain a bit more about what’s going on here in the next lab session, but for now please
just follow the instructions.
Now disconnect your Pi. Pull out the Micro-USB cable, the ethernet cable, and the mouse/keyboard USB cable. Unplug your Pi power supply. Please make sure you reconnect the USB
connector for use with the PC as a courtesy to the next user, and make sure the red dots align.
Leave the desktop PC booted into Linux, but reset its display from DVI-D to be DisplayPort
again.
That’s all we want you to do with the Raspberry Pi for this session, and we’ll start using it in
earnest in the next session. When you have completed the work for this session, please tell the
lab supervisor so we know how you’re getting on. Remember, if you don’t finish it during the
lab session, try to do so before the next one.
Keep your Pi safe, and bring it, and the power supply, and this set of notes to all the introductory lab sessions.
We’ll finish this lab with some reading about Unix and Linux – you can read this in your own
time, but make sure you read it.
0.8
Unix and Linux
Over the next couple of weeks you will be undertaking a number of introductory labs to familiarise yourself with the School’s computing infrastructure. Much of this is based on devices
and machines running Linux, a variant of the Unix family of operating systems; here we provide some background on Unix and explains why we think it is important. It would very
useful if you could read this before you attend the early labs, where the emphasis will be on
leading you through a series of tasks to explore our setup.
19
Welcome
0.8.1
Getting started
Operating Systems
An operating system (OS) is a suite of software that makes computer hardware usable; it
makes the ‘raw computing power’ of the hardware available to the user. You’re probably most
familiar with the Microsoft Windows and Apple OS X families of operating systems for
‘desktop’ computers, and iOS (Apple, again) and Google’s Android for mobile devices; but
many other more specialist operating systems exist, and you’ll be studying some of these and
the principles that underpin OS design in COMP25111 in your second year. In the meantime,
a potted history of OS development will tide us over. . .
W
W
W
W
0.8.2
W
Unix Origins
In the late 1950s, an American company called Bell Laboratories decided that they needed
a system to improve the way they worked with their computer hardware (it’s probably quite
hard to imagine what interacting with a computer without an operating system might be; but
it wasn’t pretty and involved manually loading and running programs one by one). Together
with the General Electric Company and the Massachusetts Institute of Technology , they
set about the design of an operating system they called Multics : the ‘Multiplexed Information
and Computing Service’. Multics was hugely innovative, and introduced many concepts that
we now take for granted in modern operating systems such as the ability for more than one
program to run ‘at once’; but it did rather suffer from ‘design by committee’, and the final
system was seen at the time as being overly complex and rather bloated (‘bloated’ is all a
matter of perspective of course: it’s sobering to realise though that the entire Multics operating
system was only around 135Kb. Today’s operating systems are something like 30,000 times this
size. . . ). In the late 1960s, a group of programmers at Bell Labs created a cut-down, leaner and
cleaner version of Multics that would work on more modest hardware. Legend has it that this
was to allow them to play their favourite (only!) computer game, Space Travel . In an early
example of the trend of giving things ‘punny’ names, to contrast with the more clumsy Multics,
they called this new system Unix. The so-called Jargon File is a good source of explanations
of various bits of computer slang and their obscure origins, and is well worth a read: in part
to give some background history, but mostly as an insight into the minds of the computing
pioneers of the past!
W
W
W
W
W
W
Even though Unix is now quite old, most Computer Scientists recognise that the designers of
Unix got most of the fundamental concepts and architecture right. Given how much computing has changed since the 1960s, this was an astonishing intellectual achievement. Although
Microsoft’s Windows is by far the most common operating system on desktop machines, the
majority of the Internet, much of the world’s corporate infrastructure, virtually all supercomputers, and even some mobile devices are powered by Unix-like operating systems. So, while
the polished graphical user interfaces of Windows and OS X appear to dominate the world
of computing, most of the real hard-core and leading-edge computation relies on an elegant
operating system designed nearly 50 years ago (by a team of scientists who wanted to play a
game).
W
W
0.8.3
Modern Unix Variants
The history of Unix is complex and convoluted, with the system being updated, re-implemented,
and mimicked repeatedly over the years, primarily by commercial companies who guarded
their versions jealously. Figure 14 shows a tiny fragment of the Unix’s ‘family tree’ (the full
20
4.0
9
SunOS 4.0.3
may 1989
NeXTSTEP 1.0
september 18, 1989
SunOS 4.1.1
(Solaris 1)
november 1990
SunOS 4.1
march 1990
SunOS 4.1.2
(Solaris 1.0.1)
december 1991
Solaris 2.0
(sparc)
(SunOS 5.0)
july 1992
NeXTSTEP 2.0
sept. 18, 1990
Welcome
Mach 2.6
NeXTSTEP 2.1
march 25, 1991
OSF/1
1990
NonStop-UX B00
august 22, 1989
SCO UNIX System V/386
release 3, 1989
OSF/1
1992
Sinix 5.20
1990
GNU
(GNU/Hurd)
may 7, 1991
Plan 9
1990
AMiX 1.1 (Amiga Unix SVR4)
1990
UNIX System V/386
Release 4
ASV (dev release)
1991
Unicos 5.0
may 15, 1989
HP-UX 7.02
(S800)
H2 1989
CTIX 4.0
HP-UX 3.1
feb. 1989
BOS
1989
HP-UX 7.06
(S800)
H2 1990
Microport Unix SVR3.2
Microport Unix SVR4.0
HP-UX 8.0 (S300/S800)
march 27, 1991
Dell Unix SVR4.0
1990
HP-UX 7.0
(S300/S800)
H2 1989
Dell Unix SVR1.1
november 1, 1989
Linux 0.01
august 1, 1991
AIX PS/2 & AIX/370
1.2
march 30, 1990
AIX PS/2 1.1
march 31, 1989
Venix 3.2.3
AIX/6000 v3
1989
Coherent 3.0
AIX PS/2 & AIX/370
1.2.1
february 22, 1991
HP-UX 8.01 (S700)
february 1991
Venix 3.2.4
SunSoft UNIX
Interactive 4.1
1992
HP-UX 8.02 (S800)
august 5, 1991
Linux 0.02
october 5, 1991
HP-UX 8.05 (S300/700)
july 1991
AIX/ESA 1
1991
AIX 3.2
1990
AIX 3.1
1990
Trusted XENIX 4.0
september 17, 1993
UnixWare 1
Unix System V
Release 4.2
november 2, 1992
Chorus/MiX SVR4
1991
Unicos 6.0
february 14, 1991
Xinu
HP-UX 7.08
(S800)
H1 1991
A/UX 2.0
june 1990
IRIX 5.0
march 1993
NonStop-UX B2
november 22, 199
Trusted XENIX 3.0
april 8, 1992
AMiX 2.2
Atari Unix
1989
UnixWare 1.1
Unix SVR4.2
may 18, 1993
ASV (final release)
august 1992
Dynix/ptx 2.0.4
1993
Unicos 7.0
october 29, 1992
Unix System V
Release 4.1ES
december 1992
Microport Unix SVR4.1
HP-UX 8.06 (S800)
H2 1991
HP-UX 9.0 (S800)
october 7, 1992
Dell Unix SVR4 Issue 2.2
1992
HP-UX BLS 8.04 (S800)
H2 1991
Linux 0.95
Linux 0.12
march 8, 1992
january 16, 1992
HP-UX 9,01
HP-UX 8.07
(S300/S700)
(S300/S700)
november 2, 1992
november 21, 1991
MVS/ESA OpenEd
march 26,
HP-UX 9.02
august 1993
Dell Unix SVR
199
Linux 0.99.11
july 18, 1993
AIX/ESA 2.1
1992
Coherent 4.2
may 1993
Coherent 4.0
may 1992
A/UX 3.0
april 16, 1992
Linux 0.
march 2
Veni
Minix 1.5
december 1992
AIX 3.2.4
july 1993
A/UX 3.0.1
AIX PS/2 1.3
october 2, 1992
Figure 14
A fragment of Éric Lévénez’s Unix History chart, reproduced with permission and showing
the beginnings of Linux in amongst other versions of Unix.
diagram, which you can find at www.levenez.com/unix/unix.pdf, is many times the size
of the portion you can see here).
Although many of the branches represent interesting innovations of one kind or another, there
are perhaps two that deserve particular attention. The first of these was the decision by Apple some time around the turn of the millennium to drop their own—highly popular, but
ageing—bespoke operating system (unimaginatively called Mac OS 9 ) in favour of a Unixbased system (now the more familiar ‘OS X’, where ‘X’ is both the Roman numeral ‘10’ and
a nod in the direction of the uniX nature of the OS). Although the majority of Mac users are
blissfully unaware of the fact, behind the slick front-end of OS X, sits a variant of Unix. The
second, and perhaps more profound of these events was the creation in 1991 by Swedish programmer Linus Torvalds of a Unix-like system, the source code to which he gave away for free1 ;
this became known as the Linux Kernel . Combined with other free software created by the
Free Software Foundation , a non-commercial version of Unix called GNU/Linux was born
(GNU here is a recursive acronym for “GNU’s not Unix”, a swipe at other commercial nonFree versions; much to the annoyance of the Free Software Foundation, GNU/Linux is almost
always called just ‘Linux’2 .)
W
W
W
W
NeXTSTEP 3.1
may 25, 1993
Sinix 5.40
1992
IRIX 4.0.4
march 1992
IRIX 4.0
september 1991
Trusted XENIX 2.0
january 9, 1991
Solaris 2.2 (sparc)
(SunOS 5.2)
may 1993
Getting started
Mach 3
UNIX Time-Sharing System
Tenth Edition (V10)
october 1989
SunOS 4.1.3
(Solaris 1.1a)
august 1992
Solaris 2.1
(SunOS 5.1)
december 1992
NeXTSTEP 3.0
september 1992
Solaris 2.0 (x86)
end 1992
W
Linux has been, and continues to be, developed cooperatively by thousands of programmers
across the world contributing their effort largely free of charge (although many are now paid
to work on Linux as part of their job). It is amazing to think that such a project could ever
happen—and it is surely a testament to the better side of Human Nature. But what is interesting is the observation that these programmers are not motivated by commercial concerns, but
1
‘free’ here in the sense both of ‘freedom to reuse or adapt’, and also in the sense of ‘without charge’.
Linux is pronounced “Linn-ucks”, despite the fact the name was coined by its creator, and his name ‘Linus’ is
pronounced “Leen-uss”!
2
21
Welcome
Getting started
Figure 15
A photograph of Liraz Siri’s ‘rooted’ kindle, showing the Linux command prompt. Reproduced
with the author’s kind permission from www.turnkeylinux.org/blog/kindle-root
by the desire to make good reliable software and have it used by lots of people. Thus, Linux
is a good choice of Unix: it’s Free, it’s efficient, and it’s reliable, and it is now used by large
corporations, governments, research labs and individuals around the world. Even Google’s
Android platform is a Linux-based mobile OS, and the Amazon Kindle is also a Linux box
behind the electronic ink of its user interface (Figure 15).
W
W
One of the results of the fact that Linux is Free is that several organisations and companies
have created their own distributions of it; these vary a bit (in fact, anybody is free to make any
change they like to Linux, and pass it on to whoever wants it). The distribution we use in this
School is Scientific Linux, which is based on a distribution by a US company called Red Hat.
So, if you are to become an expert computer professional, it is important that you understand
the theory and practice of Unix based systems. Learning Unix is not only a crucial skill for
any serious computer scientist, it is a very rewarding experience; the labs over the next couple
of weeks are designed to help you become familiar with what will be your daily working
environment.
When you have completed the work for this session, please tell the lab supervisor, so we know
how you’re getting on.
Reminder: keep your Pi safe, and bring it, and the power supply, and this set of notes to all
the introductory lab sessions.
22
Intro Lab Session 1
Getting started with Raspberry Pi
Contents
1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
1.2
Processes and the Unix Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
1.2.1
The process ‘family tree’ . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
File systems and files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
1.3.1
The Unix filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
1.3.2
Files in more detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
The Colossal Cave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
1.4.1
35
1.1.1
1.3
1.4
Installing Frotz, a Z-Machine Interpreter . . . . . . . . . . . . . . . . .
23
1.5
Quake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
1.6
RTFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
1.7
Shutting down your Pi safely . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
1.8
What have you learned? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
These notes are available online at
syllabus.cs.manchester.ac.uk/ugt/COMP10120/labscripts/intro1.pdf
We suggest you use the online version so that you can follow web links.
1.1
Introduction
This and subsequent introductory labs contain a large amount of material. Don’t worry if you
can’t complete it all during the timetabled lab session, but you should try to catch up outside
the lab before your next session. As always, if you’re having problems, please tell someone
and ask for help!
1.1.1
Using the Pi
If all went well in the last lab session, your Pi should be ready for use, but if you did not
complete the Raspbian configuration, please go back to the Welcome Lab 0 notes and finish it
now.
September 8, 2017
23
Introductory Labs
Getting started with Raspberry Pi
username
working
directory
[email protected] ~ $
hostname
type
after
this
Figure 1.1
The different components of the Pi’s default command prompt.
In this session we are going to complete the setup of your Raspberry Pi and explore some of
its capabilities. Please connect your Pi as you did in the previous lab, including the network
cable.
At the login line enter pi as the username, and when prompted for the password, type the
password you set in the first lab. Note that, so that anyone standing behind you cannot even
see the length of your password, the username will appear on screen as you type it, but
the password will not (so make sure you’re typing carefully!). Not echoing anything during
password typing is fairly universal in Unix systems.
You should now see:
Last login: Sat Sep 2 14:46:27 2017
Linux raspberrypi 4.9.35-v7+ #1014 SMP PREEMPT Fri Jun 30 14:47:43 BST 2017 armv7l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
[email protected] ~ $
The last line of this text (which is shown in bold here but will be green and blue on your
screen) is the command prompt . It might look innocent enough, but in the right hands, the
command prompt is one of the most powerful ways of controlling a computer. Your previous
interaction with a computer was probably via a graphical user interface , or GUI, such as that
provided by Windows or macOS, so it may feel a bit odd at first to be issuing instructions to
a machine via a textual command-line. However, this is a crucial skill that you’ll need during
your studies here at University, and also in your future career. In fact, employers have often
said that our students’ abilities with the command-line come as a very pleasant surprise to
them and set them apart from many other students.
W
W
The default command prompt on the Pi consists of four components shown in Figure 1.1.
• To the left of the @ symbol is the name of the user, and in this case that’s pi, since you’ve
just logged in under that name
• To the right of the @ is the hostname of the machine, which on a Raspberry Pi is quite
reasonably set to raspberrypi by default.
24
Introductory Labs
Getting started with Raspberry Pi
Breakout 1.1: Don’t be a WIMP
The familiar Windows, Icons, Menus and Pointer (WIMP) paradigm used
on most graphical desktop environments is enormously powerful, but it’s
not suitable for every task, and understanding when you’re better off using
the command-line or a keyboard shortcut instead will make you a lot more
efficient.
Sometimes the clumsiness of the GUI comes from the fact that there’s no convenient visual
metaphor for a particular action; how do you graphically represent the concept of ‘rename
all the files I created yesterday so they start with a capital letter’?
But a lot of the time the issue is simply that it takes much longer to do some things with
the mouse than it does with a keystroke or two. Every time you use the mouse, a little
time is wasted shifting your hand off the keyboard and a little more time used up tracking
the pointer between the on-screen widgets. For casual use, this wasted time really doesn’t
matter. But as a computer scientist you’re going to be spending a lot of time time in front
of a machine, and all the seconds wasted moving the mouse pointer around add up.
What’s really fascinating here, though, is that although the keyboard versus mouse debate
is one that has been running since at least the mid-1980s, there isn’t a clear winner, or even
any definitive guidelines as to when one is better than the other.
In any case, you should definitely learn the keyboard shortcuts for the most common operations in your favourite tools, and a handful of useful command-line tools. For example,
when you’re writing code you’ll be saving files very regularly; maybe even several times
a minute when you’re debugging. There are two options for this: 1) move hand off keyboard to mouse; use pointer to find the ‘File’ menu, from the file menu move the pointer to
the ‘Save’ option; move hand from mouse back to keyboard. Or 2) Press the combination
of keys that perform the ‘save’ function. Which do you think is faster?
And think carefully about the best tool for the job; sometimes it’ll be the mouse/menu
combination, but perhaps more often than you might think, a few selected commands
may get the job done considerably more quickly. You’ve probably had more experience of
doing things the GUI-way up until now so, during these labs, please use the commandline wherever possible to built up your familiarity until you are able to judge the pros and
cons of both approaches to make an informed decision each time.
• The ~ tells you where in the Pi’s file system you’re currently working. We’ll explain this
in a lot more detail later on, for now all you need to know is that the ~ symbol is called
a tilde (pronounced something like till-duh, though it’s often referred to colloquially just
as a ‘twiddle’), and is used here to refer to the ‘home’ of the current user.
• On the Pi the default prompt ends with the $ symbol.
You can change this prompt to something more or less verbose later, but for now we’ll leave
it as it is. For simplicity in these notes, we’ll use the $ symbol from now on to mean ‘type
something at the command prompt and press Enter’. So for example
$ echo Hello World
means ‘type echo Hello World at the command prompt and then press Enter’ (you can do
this if you like; the result will be that ‘Hello World’ gets ‘echoed’ back to you on the next line
25
echo
Introductory Labs
Getting started with Raspberry Pi
Breakout 1.2: Ping
The ping command is named after its use in the field of active sonar, where
an actual ‘ping’ sound was sent through water, and distance calculated by
listening for the echo to return. It’s the classic boingy pingy noise associated
with submarine movies!
of the screen). (Notice that this reference to a Unix command has caused a small cog to appear
in the right hand margin, so you can find this reference easily later. If you are reading the notes
online, the cog also contains a link to a web page describing some Unix commands.)
To confirm that you’re now connected to the network, use the ping command, which sends
a low-level network message to a designated place and checks for a response, to see if you
can reach our School’s web server. Don’t worry about the sudo part, we’ll explain that later
in the lab. You will be prompted for your password here, again don’t worry about this for the
moment.
ping
$ sudo ping www.cs.manchester.ac.uk
PING cmpsci.eps.its.man.ac.uk (130.88.98.241) 56(84) bytes of data.
64 bytes from eps.its.man.ac.uk (130.88.98.241): icmp_req=1 ttl=61 time=0.949 ms
64 bytes from eps.its.man.ac.uk (130.88.98.241): icmp_req=2 ttl=61 time=1.01 ms
64 bytes from eps.its.man.ac.uk (130.88.98.241): icmp_req=3 ttl=61 time=0.861 ms
Each of the lines starting with ‘64 bytes’ represents a short response from the machine you’ve
just pinged, and you’re shown the round-trip time for ping’s data to leave your Pi, find (in
this case) www.cs.manchester.ac.uk on the network, and return back to your Pi. Since
we’re just using ping here to give us some confidence that the network is okay, we don’t need
to leave it pinging away for ages, so let’s stop the ping command in its tracks. Hold down
the control key (marked ‘ctrl’ on the keyboard), and press ‘c’. This will signal the currently
executing command that it should stop what its doing and return to the command prompt
(quite often this is referred to as “control-c-ing” a command, and it will have the same effect
on the majority of command-line tools). This key combination is often written <ctrl>c.
If you see this notation in these notes, don’t type the individual characters, press the key
marked ctrl and the appropriate letter key.
The readout from the ping command is important - you should check which machine exactly
is responding to your pings. If your network is configured correctly you should find that the
output from the ping command looks similar to the one here, including the domain name
eps.its.man.ac.uk and the IP address 130.88.98.241. You shouldn’t worry about subtle differences such as the time, but if the IP address looks much different to this (for example,
if it is 10.2.232.254) then you likely failed the registration from Intro Lab 0 and should
return to complete that step.
1.2
Processes and the Unix Shell
Before doing anything else, let’s take a few steps back and look in a bit more detail at what
you’ve just done; you may be surprised how much stuff happened as a result of that simple
command you’ve just typed.
26
Introductory Labs
Getting started with Raspberry Pi
The first concept you’ll need to understand is that you have been interacting with what is
known in Unix circles as a shell : a program that prompts the user for commands, accepts
them, executes them and displays the results. A shell is just a program running on the Linux
operating system like any other program—it’s not ‘built in’ to the computer or the operating
system in any special way, it just happens that by default, the Pi is set up so that when a user
logs in, the first program that gets executed on behalf of that user is an interactive shell that
allows users to execute further programs themselves. The shell that we are using here is called
bash, a name we will explain a little later.
W
But what do we mean by ‘execute commands’? And if the shell is ‘just a program’, how does
it get to communicate with the keyboard and screen? What is a ‘command’ anyway, where do
commands come from?
To understand what’s going on here you’ll need to make sense of a concept that’s fundamental to pretty-much any operating system; that of a process . As you no-doubt know, modern
computers have one or more Central Processing Units (CPUs) which are capable of carrying
out simple instructions; a basic computer like your Pi will have a single CPU, whereas a big
server machine or supercomputer may have several tens of CPUs in a single box. To a first
approximation, each CPU is only capable of following one instruction at a time, and the illusion that a computer is capable of doing a very large number of things simultaneously (e.g.
streaming music, displaying web pages, downloading a video of a unicycling kitten and playing Minecraft ) is achieved by the operating system arranging for each of these tasks to be
given access in turn to the CPU for a tiny fraction of a second. More technically, these tasks
are called processes . The relationship between anything that you as a user may recognise—
for example a desktop application—and what’s happening in the operating system in terms
of processes is quite complex, since many applications are made up of several processes, and
there will be a whole load of other processes doing housekeeping jobs that aren’t immediately
obvious to a user. But for now we’ll gloss over this detail and work on the assumption that
when you ask a computer to do something for you, a process will be started to deal with that
task for you.
W
W
W
W
In terms of what’s just happened when you ran the ping command a moment ago, there are
at least two processes involved. The shell program itself is a process that’s waiting for you to
type something at the keyboard; when you pressed enter after having typed your command,
the shell interpreted your input, and started up a second process to run the ping program for
you. It handed access to the keyboard and monitor over to the process running ping, and then
went to sleep briefly to wait for the ping command to finish. When ping finished (in this case
because you aborted it), the shell woke up again, took back control of the keyboard/screen,
and was ready for your next instruction. This is illustrated in Figure 1.2.
You will learn much more about processes and the way they are managed in COMP15111 and
COMP25111; for now there’s one more thing you need to understand about the relationship
between processes.
1.2.1
The process ‘family tree’
When the shell’s started up a process to run your command, the new process (the one that’s
running the command) is thought of as a ‘child’ of the shell’s process. The child inherits many
of the properties of its parent (you’ll see why this is important in the next Pi lab).
27
Introductory Labs
Getting started with Raspberry Pi
Process 1
(bash)
Process 2
(ping)
1
3
Time
2
5
4
Figure 1.2
Running a command at a bash shell involves two process, one for the bash shell itself, and
a second child process that is started by the bash shell in which to run the command: 1
initially, just the bash process is running. 2 at the point where you type the ping command
and press enter, bash starts a second process and hands over its input and output to that
new process, which executes the command on your behalf; at this point the bash process
continues to exist but ‘goes to sleep’ until the command finishes. 3 the new process starts
up, and executes your command, until at 4 it’s either aborted by the user or finishes what
it’s doing, at which point 5 the ping process terminates and hands back control to the shell,
which wakes up ready to accept the next command.
1.3
File systems and files
Next we’re going to explore the Pi’s filesystem a little. You’ll be familiar with the idea of a
hierarchy of files and folders from whatever graphical environment you’re used to using on
desktop or mobile devices: files represents things that you’ve created or downloaded such
as documents, images or movies, and folders are a way of organising these into related collections. By putting folders inside folders, you can organise your stuff starting with general
concepts such as ‘Photographs’ and ending up with much more specific collections, e.g. ‘Holidays’, then ‘Bognor Regis 2013’.
Interacting with a standard Unix filesystem via the command-line uses similar concepts (actually, it’s the graphical environment that’s being ‘similar’ here really, since the Unix commandline existed quite some time before anything graphical appeared). Files are called files, but
what are commonly represented as ‘folders’ in graphical environments are more correctly
called ‘directories’ when we are operating at this level (and we’ll call them directories from
now on, because it’ll make some of the command names and manual pages make more sense).
Let’s first see what stuff we already have on our Pi. The ls command lists files and directories.
28
ls
Introductory Labs
Getting started with Raspberry Pi
Breakout 1.3: Unix shells
Unix has many shells: the first shell was called the ‘Thompson’ shell (also
known as just ‘sh’, and pronounced “shell”), written by Ken Thompson for
the first Unix system; then came the ‘Bourne’ shell (also called ‘sh’), written
for a later commercial version of Unix by Stephen Bourne. You have just
been using the Free Software Foundation’s ‘Bourne Again’ shell (a pun-name taking a
dig at its commercial fore-runner), or ‘bash’. The various different shells offer the user
different facilities: ‘sh’ is rather primitive compared to the more modern ones. However,
their basic functionality is always the same: they accept commands from the standard
input (for now, we can treat that as meaning ‘the keyboard’), execute them, and display
the results on the standard output (i.e. for now ‘the screen’, which in this case was the
entire screen, or console). Shells repeat this process until they have reached the end of
their input, and then they die. Unix shells are rather like Command Prompt windows in
Microsoft Windows, except that Unix shells are considerably more sophisticated.
Type it now, and you should see that a directory called python_games has already been created
for you, and other directories that you can ignore for the time being.
$ ls
python_games
When we’re using a command-line prompt, we have the notion of current working directory
which is the directory that we’re currently ‘in’ (so in this example, using ls like this really
meant ‘run the list command on my current working directory’). There are numerous Unix
commands that allow you to move around the filesystem’s directory structure, and it’s very
important that you become familiar with these early on.
W
Let’s say we want to look at the contents of the python_games directory. There are several
ways of doing this, but for now we’ll break the process down into simple steps. Use the cd
command to Change Directory to python_games:
$ cd python_games
Here we have a command, cd, together with an argument, python_games which specifies the
object on which the command is to operate.
Now look at what’s happened to the command prompt. Whereas before it was just
[email protected] ~ $
it has now become
[email protected] ~/python_games $
to indicate that we’ve changed our current directory to python_games (remember the ~ symbol means ‘home directory’, so ~/python_games really means ’a subdirectory called python_games
which is in my home directory’).
Now use the ls command to list the contents of our new current working directory. You
should see a long list of files: some are programs written in the Python programming language
29
cd
Introductory Labs
Getting started with Raspberry Pi
(these files end in .py), others are images or sounds used by those programs (ending in .png
or .wav). At the prompt type:
$ python wormy.py
to start a simple version of the classic ‘Snake’ game. You can guide your green snake around
the screen with the cursor keys; you score a point every time you eat one of the red squares and
an extra segment gets added to the length of your snake. The game finishes if you crash into
the edge of the screen or eat yourself. Once you’ve convinced yourself this is working (don’t
spend too long playing the game!), press the Escape key to return to the command prompt.
You’ll be writing a version of this game soon enough in the Java labs.
1.3.1
The Unix filesystem
In Unix, as with most other operating systems, the files and directories you create can have
more or less any name you like. It is very sensible to give them names which mean something
and make their purpose clear. This is despite some of the traditional file names in Unix being
rather cryptic—this is particularly true for most Unix commands. You’ll get used to that.
File name formats. The filesystem on your Pi (which uses a type of filesystem called ‘ext4’) is case sensitive, which means that Hello.txt and hello.txt
are treated as different files because they have different case letters in their
names. The filesystem used by Microsoft Windows since XP (called ‘NTFS’)
is also case-sensitive. Apple’s macOS, however, uses ‘HFS Plus’ (which
usually appears as ‘Mac OS Extended (Journaled)’), and this is not a proper
case-sensitive file system; although it will remember whether you called a file
Hello.txt or hello.txt so files appear to be case sensitive, the OS itself
treats them as being the same file! The same is true for the FAT32 filesystem
used on most removable USB drives – because it’s one of the few formats
that’s understood by Windows, Mac and Linux.
Most of the time this isn’t a problem, but you should be careful of the effects
when copying files from one filesystem to another, especially if you are using a USB drive to transfer files from a Linux box to somewhere else. For
example, if you have two files in the same directory on Linux with the same
name but with different capitalisation, one file will overwrite the other when
you copy them onto your USB drive (and which one survives will depend on
the order in which they are copied). One way around this problem is to use
commands such as tar or zip to bundle the files up into a single archive file,
and then transfer that via the USB drive.
tar
As you already know, directories are created within directories to create a hierarchical structure. The character / (slash) is used to separate directories, so if we wish to talk about the file
y within the directory x we write x/y. Of course, y may itself be a directory, and may contain
the file z, which we can describe as x/y/z.
But where is the ‘top’ directory? Surely that has to go somewhere? On each machine, there
is one directory called ‘/’ which is referred to as the root, which is not contained in any other
directory. All other files and directories are contained in root, either directly or indirectly. The
root directory is written just as / (note this is the opposite slanting slash character to that used
in Windows).
30
Introductory Labs
Getting started with Raspberry Pi
You can think of this structure as defining a tree, with / as the root (hence its name), directories
as branches, and other files as leaves. You will study trees as abstract data structures, later in
this year, and in Year 2, but this simplified model of the Unix file system structure will do for
now.
One really important, and slightly strange thing to get used to, though, is that computer science trees grow upside down, so although we call them trees, the ‘root’ is usually thought
of as being at the top, and the ‘leaves’ at the bottom. You’ll hear phrases like ‘go up to the
root directory, and then down one level to the home directory’. We normally think of the root
directory as being at the top of the tree. (For those of you who are interested: Unix actually
allows links, which means the structure can really be a cyclic graph . Links are similar to, but
fundamentally not the same thing as, shortcuts in Windows.)
W
Apart from / there are two more directories of special note:
• Your home directory is the directory where you find yourself when you log in. It might
be tempting to think of this as being the ‘top’ of the tree (and for every-day purposes
thinking this way is probably okay), but in reality your home directory is probably one
or more levels away from the root of the file system. We’ll find out where this is on the
Pi shortly.
• Your current working directory is the one you are working in at a particular moment.
So let’s see where we are in the Pi’s filesystem at the moment. Assuming you’re following these
instructions properly you should still be in the python_games directory (check the command
prompt to confirm this is the case). To go back to our home directory, we can use the cd
command without an argument:
$ cd
You should see the command prompt change back to being as it was when we first logged
in. So where in the filesystem is our home directory? We can find out where we currently are
using the pwd command, which stands for Print Working Directory:
$ pwd
/home/pi
So apparently we’re in a directory called /home/pi which sounds plausible enough. Notice
that the pwd command has returned us an absolute pathname , that is, it starts with a / character. Absolute paths, such as /home/pi are given by their ’steps’ from the root. So we now
know that the home directory for the user pi is in a directory called home which itself is a
subdirectory of the root /.
W
Let’s confirm that this is true. Issue the command:
$ cd /
which just means ‘change directory to the root directory’ and use the ls command to look
at the root directory’s contents. You’ll see several directories with names like bin, boot, dev
and lib. Most of these contain ‘housekeeping’ files for the operating system, and at this stage
you don’t need to know what’s in them (Appendix 5.1 gives you a brief description if you’re
interested). The one called bin is quite interesting though, so let’s investigate that by typing:
31
pwd
Introductory Labs
Getting started with Raspberry Pi
$ cd bin
$ ls
Here the argument to cd is not an absolute pathname (starting with /) but a relative pathname
(not starting with /). A relative pathname can be thought of as a ‘pathname starting from
here’, where ‘here’ means the current working directory. So, because we are in /, the relative
pathname bin refers to the directory /bin.
The above commands should have produced a fairly long list of files. Look carefully, and you’ll
find two names that you recognise: ls and pwd. Files like these are called binary executable
files and are the programs run when the commands are used (which is why they are in the ‘bin’
directory, which is short for binary). In Unix, most commands are not ‘built into the system’,
but are just programs put in a special place in the filesystem that are picked up by the shell
when you type things. This makes Unix very easy to extend with new features; you just write
a program to do what you want, and put it in the right place. We’ll look at how the system
knows where to find commands later, and explore several of the other commands you can see
in this directory as well.
We now need to get back to our home directory. There are many ways of doing this, including
the following:
1. cd on its own means ‘take me directly to my home directory’
2. We know that the tilde symbol also means ‘my home directory’, so cd ~ will also work
(though at the expense of two extra keystrokes!)
3. We could go back to the root directory by first typing cd /, then cd home and finally cd
pi
4. We could go back to the root directory by first typing cd /, then cd home/pi
5. We could go straight from where we are now (which is /bin, remember) by typing cd
/home/pi – use this method now
Now we’re back in our home directory (check the command prompt to make sure), you may
have noticed that our commands for navigating around the filesystem are missing one feature.
We can go to the ‘top’ of our home directory easily enough; and we can go straight to very
top of the whole filestore using cd / ; and we know how to descend into a subdirectory (e.g.
cd python_games). But how do we go up one level? If we were in some nested subdirectory
several levels below our home, and wanted to go just one level back up the tree, it would be
very tedious to have to start back at our home directory and traverse back down to where we
wanted to be.
Unix represents the idea of going ‘up’ one directory with the .. symbol (that’s two fullstops
typed immediately after one another with no spaces, usually pronounced ’dot dot’.). So if you
are in, say, python_games and want to go back up to the directory above, you could type:
$ cd ..
We use .. whenever we we want to specify a move up the directory tree. So, assuming you
are still in python_games, how could you get into /bin using only a relative path in the cd
command? Yes, this is a slightly artificial exercise because the simplest solution would just be
to use the absolute path cd /bin, but just go with the flow for now and work it out using a
relative path. The answer is shown in Figure 1.3.
32
Introductory Labs
Getting started with Raspberry Pi
(1) this goes
to our home
directory
/home/pi
/
(3) next up
another level
to /
bin
home
cd ../../../bin
pi
(2) then up
one level to
/home itself
(4) finally, down
one level into
/bin
python_games
Figure 1.3
Given the Pi’s default filesystem structure, starting in the python_games directory, the command cd ../../../bin will take you to the /bin directory (by an admittedly tortuous
route!)
We can also refer to the current directory in a similar manner. Just as the directory above is
referred to as .., the current directory can be referred to as ., or ‘dot’. So the relative pathname
x/y/z refers to exactly the same place as ./x/y/z
1.3.2
Files in more detail
The files we’ve looked at so far, and the behaviour of the commands we’ve used to manipulate
them shouldn’t feel too alien—we’re just doing similar things on the command-line to actions
that you’ll have performed using a graphical interface before. But the Unix take on files is
rather more sophisticated than this, and to understand that, we’ll need to think in a bit more
detail about what a file actually is. When we think of an image or a music track as being stored
‘in a file’, what do we actually mean?
A file is actually just a sequence of numbers on some storage device such as a hard drive. The
right program can interpret these numbers, and turn them into pictures on screen, or sounds
coming out of your speakers. The wrong program would be able to make no sense of a file at
all; if you could ‘display’ an audio track on screen, or ‘play’ an image file as sound, it would
just be a meaningless mess. So there’s nothing very special about a file that makes its contents
mean one thing or another; it’s just up to a program to interpret what’s in the file correctly. So
what are the properties of a file? So far we’ve seen that files have a filename, and a location
within a file system. We’ve seen that some files can be executed, whereas other files contain
data. But in both these cases, files are just sequences of numbers. Although we’ve not explored
this yet, some files can be written to or modified, whereas others can only be read from; but
they are still just sequences of numbers which when interpreted correctly have a particular
meaning.
The designers of Unix exploited this idea to create a very elegant way of representing the
hardware of the underlying computer, and many of the properties of the operating system by
treating anything that can be thought of as behaving like a file as being a file.
What, for example, might a hard disk look like to the operating system? Well, a hard disk is a
device that can store a long sequence of numbers, and if you interpret those numbers correctly,
33
Introductory Labs
Getting started with Raspberry Pi
they can be made to represent a filesystem. So as far as Unix is concerned, a hard disk is a bit
like a file that you can read from and write to.
What about a process? Well that’s a sequence of numbers in memory that happen to be instructions to the CPU to do useful things; so that’s a file too (probably in this case a read-only
file).
What about a keyboard? Surely that’s not a file? Actually it can be thought of as having some
file-like properties; it’s a stream of numbers that represent the keys pressed by the user, so it
too is a sort-of read-only file. And the screen? That too is file-like. . . because it represents a
sequence of numbers that can be interpreted as the output from various processes; so it’s a bit
like a write-only file.
This may seem all a bit esoteric and confusing right now, but as we explore more examples of
these file-like things, you’ll start to see how elegant the idea is.
For now, to give this stuff about files some time to sink in a bit, let’s play another game.
1.4
The Colossal Cave
We’re now going to explore a bit of computing history, and install and play one of the very
early computer games. Colossal Cave Adventure was the first ‘adventure game’, in which
a virtual world is described using only text, and the player controls the game’s protagonist
using simple textual commands. The game was created in 1976 by a keen caver called Will
Crowther who at time was a programmer at Bold, Berenek & Newman, the company that
developed ARPANET , the forerunner to the modern Internet. He later collaborated with Don
Woods , then a graduate student at Stanford University, to create the Colossal Cave Adventure
as we would recognise it today. The original version consisted of around 700 lines of the
FORTRAN programming language and a similar number of lines of data. When running on
a PDP-10 (see Figure 1.4 for a picture of what one of these machines looked like) Colossal
Cave would consume around half of the machine’s memory. To put this in perspective, the
tiny Raspberry Pi computer on your desk has roughly 1000 times as much memory as the
PDP-10; it can run Colossal Cave with ease.
W
W
W
W
W
Although the original FORTRAN source code for Colossal Cave still exists, the version you’re
going to play with is based on a re-implementation of the game on what became known as
the Z-Machine : a virtual machine specifically for running interactive fiction games, such as
Colossal Cave.1
W
W
1
Don’t confuse the Z-machine, which is a virtual machine for adventure games, with the Z Machine, which is
the largest X-ray generator in the world. Doing so is likely to make your lamp melt, and the trolls very grumpy.
34
Introductory Labs
Getting started with Raspberry Pi
Figure 1.4
A
PDP-10
from
CERN,
circa
1974,
reproduced
with
permission.
cds.cern.ch/record/916840. We’ve taken the liberty of crudely superimposing a
Raspberry Pi to approximately the right scale on the operator’s desk, just to give a sense of
the difference in size between the two machines.
1.4.1
Installing Frotz, a Z-Machine Interpreter
Unlike the other commands that you’ve used so far, the program we need to be able to play
Colossal Cave Adventure isn’t pre-installed on the Raspberry Pi, so we’re going to have to
fetch and install it ourselves. Fortunately, the version of Linux that we have on the Pi comes
with a package management system that makes this quite easy.
But first, we’re going to have to understand a command called sudo. Everything that you’ve
done so far has involved looking at files that either belong to the ‘pi’ user, or are parts of
the system that can be read or executed by any user. But of course, installing a new piece of
software involves modifying the Pi’s operating system in some way, and that’s not something
that you want to do casually since mistakes could potentially mess up the whole device.
sudo
You’ll be familiar with the idea of a user with Administrator privileges from Windows or
macOS; on Linux the superuser that can do anything to any part of the system is called ‘root’
(because this user can modify any part of the system from the root of the filestore downwards).
In the early days of Unix, administrators would log in as the root user to modify, update and
repair the system. This had the major downside that all the normal safety nets that prevent
you from accidentally deleting or damaging the operating system itself are deactivated, so its
much easier for a slip of the finger or a brief moment of stupidity to have disastrous effects. To
avoid these problems, Unix systems now usually recommend the use of the sudo (’Substitute
User Do’) command to temporarily elevate a normal user’s privilege to that of super user for
a single command. sudo privileges are not normally given to every user on a Unix system, but
the user pi on the Raspberry Pi is trusted and is given sudo rights.
W
W
The system that we’re going to use to install this game is called apt, which stands for Advanced Packaging Tool . This tool maintains a list of remote repositories in which packages
W
35
apt
Introductory Labs
Getting started with Raspberry Pi
have been put that contain all the programs, libraries and data files necessary to install a particular Linux program. It can deal with fetching packages over the Internet, as well as extracting and copying their contents into the right places on your system. It also performs a series
of sanity-checks to make sure that what you’re adding is compatible with whatever you’ve
already got in place.
The system we want to install to play this game is called frotz (to learn why, you’ll have to
play the game a bit, or look it up on Google). Let’s try running the apt-get command without
having gained superuser privilege first. Try typing:
apt-get
$ apt-get install frotz
The operating system will respond with something like:
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
Notice the question at the end: ‘are you root?’. Well, no you’re not, so Linux has rightly
prevented you from performing this operation. Now we’ll try again using the sudo command.
This time type:
$ sudo apt-get install frotz
You should see a series of lines printed out on the screen, ending with:
Setting up frotz (2.43-4) ...
before being returned to the command prompt (note the version number for frotz may have
changed from 2.43-4 by the time you do this exercise, don’t worry, that’s fine). It’s possible
that apt-get will fail to find the frotz package in one of the repositories it knows about; if this
happens, it’s usually because the repository has moved somewhere else on the internet, so you
need to tell the APT system to update itself first: run the command sudo apt-get update,
and when that has completed try installing the frotz package again, and all should be well.
The frotz system on its own is just a virtual machine into which you can load adventure game
data, so we’ll need to fetch the Colossal Cave datafile before we can play anything. We’ve put
a copy of the game on the web at:
studentnet.cs.manchester.ac.uk/ugt/COMP10120/files/Advent.z5
so you can fetch it from there. Oh, hang on. No web browser. Oh dear.
Rather than browsing the web in the normal way, we sometimes want to just obtain a copy of
file; we can do this using the command curl. First, use cd to change to your home directory if
you’re not there already, then
$ curl http://studentnet.cs.manchester.ac.uk/ugt/COMP10120/files/Advent.z5 -o Advent.z5
and you’ll see curl fetch the file you need ‘over the web’ and save it in your home directory.
This is also the first time you’ve encountered what’s called a command-line argument switch:
the -o switch tells curl to use the next argument on the command-line as the output filename.
Use ls to confirm that you can see the file Advent.z5 in your home directory, then type:
36
curl
Introductory Labs
Getting started with Raspberry Pi
Breakout 1.4: APT
The APT system is a very convenient way of managing packages, since it will
automate the process of finding, fetching, configuring and installing software
on your Pi (or indeed, on other Debian-based Linux installations). The RPM
system does something similar for distributions based on Red Hat’s version
of Linux.
The various repositories that contain the packages for your Pi are updated regularly, so
it’s worth running apt-get update once in a while to refresh your Pi’s list of software.
You should also at some point run apt-get upgrade, which will cause all the packages
that have already been installed to be upgraded to the latest version that the APT system
can find. This lab will work just fine with the versions of software that are pre-installed
on your Pi, and the upgrade process can take quite some time (hours, possibly), so you
mustn’t do it now or you won’t be able to complete this lab in time. Try it at home, or
outside of a lab session.
$ frotz Advent.z5
to start playing the Colossal Cave Adventure. Once the game has started (the screen will have
gone blue), type HELP to get instructions. When you’ve had a bit of a wander around and got
the general idea of the game, you can type quit to get back to the command prompt. There
are some parallels between using commands to wander around Colossal Cave and using Unix
commands to navigate around the Pi’s filesystem.
Earlier, we referred to Colossal Cave as a work of Interactive Fiction (IF). In truth, this is perhaps stretching the term somewhat, since the genre has matured considerably in the decades
since this first adventure game. For a much more compelling example of Interactive Fiction
with beautifully written prose, and funny and challenging puzzles we suggest you have a go
at playing Curses by Graham Nelson , or one of the many other games written by Interactive
Fiction enthusiasts that are available for free from www.ifarchive.org. If you find yourself
getting hooked on playing IF, the frotz interpreter is available for most platforms, including
iOS, Android, macOS and Windows.
W
1.5
Quake
We’ll finish this lab session off with one more game.
Use curl to fetch the file hosted at
studentnet.cs.manchester.ac.uk/ugt/COMP10120/files/quake3.tar.gz
making sure you save it in your home directory. By default, curl will just output whatever
it has fetched to the screen. Use the option you learned about earlier to save it to a file called
quake3.tar.gz.
Notice that this file ends with .tar.gz. The .gz suffix tells us that this file has been compressed using a utility called gzip, so the first task is to uncompress the file. Type:
$ gunzip quake3.tar.gz
37
gzip
Introductory Labs
Getting started with Raspberry Pi
This will uncompress the file, removing the .gz and leaving you with quake3.tar. A ‘tarfile’
is a bundle of individual files that have been assembled together into a single file for convenience (you’ll probably have already encountered ‘zip’ files, which have a similar purpose).
The name ‘tar’ is an abbreviation of ’Tape Archive’, since the tar command was originally
used for making backups of filestores onto magnetic tape. It remains, however, a very versatile way of bundling up lots of things, and you’ll find tar files all over the internet.
To see what’s in this archive, run the command
$ tar tf quake3.tar
and you’ll see a long list of the archive’s contents scroll past on the screen. The first argument
to tar is a bit of an odd one, since it’s a collection of options, which unusually for Unix are not
prefixed by individual minus signs (recall the -o option we used for curl; that’s a far more
common way of specifying options to tools). In this case the options mean:
• the t causes tar to list the ‘table of contents’, for the archive, without extracting anything,
and
• the f tells tar that the next argument is the file containing the archive.
To actually extract the contents of the archive we issue the command:
$ tar xvf quake3.tar
where
• x means ‘extract’.
• v means ‘be verbose, and show what you’re extracting as you do it’.
• f again means ‘and here is the file to work on’.
When tar has finished working you’re presented again with the command prompt. Use ls to
confirm that you now have a directory called quake3 in your home directory. You might also
want to plug some headphones into the Pi at this point too, if you happen to have a pair with
you.
$ cd quake3
$ ./ioquake3.arm
This command executes the file ioquake3.arm which is in the current directory (.). After the
startup screen, the game will ask you for a code, but you can just skip this and use the mouse
to select the play option. The rest, we’re sure, you can figure out for yourself.
38
tar
Introductory Labs
Getting started with Raspberry Pi
Breakout 1.5: Multiplayer Quake?
You can play this version of Quake3 Arena with friends over the network.
We’ll leave you to figure out how to configure that yourself (hint: the
ifconfig command will tell you what IP address has been allocated to your
Pi).
1.6
ifconfig
RTFM
Although we’ve introduced several Unix commands in this lab, we’ve only done so quite
superficially in this session, giving you just enough detail to get through the tasks we’ve given
you. Each of the commands is much more powerful than what you’ve been exposed to so far.
Though you won’t need to know every possible option off by heart, there are a lot of useful
things you can learn about them quite easily.
Most Unix systems, including the one on your Pi, have an instruction-manual system that
gives more details about the available commands (and most things that you install yourself,
such as frotz also install their own manual pages). Try running:
$ man ls
for information on the ls command, and use the same trick to find out more about the other
commands you’ve seen in this session. If you need more help on how to use the man command,
you can always use:
$ man man
When you’re looking at a manual page, pressing the Space Bar will advance you on a page,
and the Up and Down cursor keys will move you back and forth line-by-line. Press q to quit
viewing a man page.
Breakout 1.6: RTFM?
The acronym RTFM stands for Read The Flipping Manual, and is sometimes
used as a response when somebody has asked a lazy question on a forum
or by email where decent documentation already exists and is easily accessible. The F is sometimes interpreted as meaning something less polite than
‘Flipping’.
39
man
Introductory Labs
Getting started with Raspberry Pi
Pi Power. Like most other computers, the Pi doesn’t like having its power
removed without being shut down properly. Although you might get away
with it, there’s a reasonable chance of messing up the operating system
if you remove the power while the Pi is in the middle of doing something.
And because the Pi runs a multi-tasking operating system, it’s almost always
‘doing something’, so pulling the power out unexpectedly is always a bad
idea. You’re unlikely to damage the Pi’s hardware like this, but you may find
that you lose work, and may have to reinstall the operating system. For
instructions on how to shut the Pi down safely, see Section 1.7.
1.7
Shutting down your Pi safely
When you’re finished playing Quake, exit the game and get back to the command prompt.
Like any other computer, it is really important that you shut your Pi down properly; if you
just pull the power cord out there’s a chance of corrupting the filesystem. To shut the Pi down
safely use the halt command:
$ sudo halt
You’ll see the a series of messages scroll past that look rather like those you saw during the
boot process. This shouldn’t be surprising, since what the operating system is doing now
is shutting down all the things that it started up when you booted the machine, roughly in
reverse order. When all these services have closed down tidily, the Pi will power itself down;
the LEDs will go off, the screen should go black, and only the red PWR LED will remain lit on
the circuit board. At this point it’s safe to pull the Micro-USB cable out of the Pi. As always,
please reconnect the USB cable ready for use by the desktop PC and reset the monitor to get
input from the PC rather than the Pi.
When you have completed the work for this session, please tell the lab supervisor.
1.8
What have you learned?
It might seem like you’ve been playing games for most of the lab, but if you’ve followed the
instructions carefully and read through all the text you’ll have learned a lot of new things.
These include:
• the anatomy of a Pi
• how to safely start and stop your Pi
• running commands, e.g.: echo, ls, cd, pwd, sudo, gunzip and tar.
• how the filestore is structured
• basic apt commands
40
halt
Intro Lab Session 2
Using the Linux desktop in CS
Contents
2.1
Logging in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
2.2
Reading email in terminal mode . . . . . . . . . . . . . . . . . . . . . . . . . .
42
2.3
Browsing the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
2.3.1
Pipes and Redirects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
2.4
X Windows and GNOME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
2.5
X Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
2.6
Window Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
2.7
Starting a graphical environment automatically . . . . . . . . . . . . . . . . .
55
2.8
ARCADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
2.9
Text Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
2.10 Shell environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
2.11 Configuring Thunderbird . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
2.12 That’s all for now . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
These notes are available online at
syllabus.cs.manchester.ac.uk/ugt/COMP10120/labscripts/intro2.pdf
We suggest you use the online version so that you can follow web links.
In this lab session we’re going to explore some of the features of Unix in a bit more depth, this
time using the desktop PCs rather than your Raspberry Pi (we’ll return to using that in the
next lab). We’ll explore some of the more advanced features of the command line and various
useful tools that will help you understand how a typical Unix system is organised. Almost
everything that you learn using Linux on the desktop machine is equally applicable to the
Raspberry Pi, and vice versa.
2.1
Logging in
Make sure the desktop PC is booted into Linux, and log in using your University username
and password (not the username and password you used on the Pi). Remember that nothing
will appear on the screen when you type your password. You should be greeted with a similar,
but rather longer, command prompt to the one you saw in the previous lab.
September 8, 2017
41
Introductory Labs
Using the Linux desktop in CS
You are now logged in to a PC that is part of our School Linux network. Type pwd to find out
which directory you are in. It should be something like /home/mbaXXXXX, where the part after
the /home/ is your username. This is your home directory, which is not actually stored on the
desktop PC but on a central fileserver. This means that, whichever machine you use in the lab,
you will always see the same home filestore.
The environment you are now in is known as terminal mode. This is a way of interacting
with the computer via a screen containing only text, without the now familiar windows and
images. All interaction is done using a command line interface (CLI), typing commands into
a program known as a shell. When the terminal occupies the entire screen, as it does here, it is
known as console mode. Later we will be using a graphical environment, but for now we will
stick to terminal mode interaction and start off by reading mail.
2.2
Reading email in terminal mode
You’re probably familiar with reading email using either a web-based interface, a graphical
desktop application (such as Outlook, Thunderbird or Mac Mail) or using an app on a smartphone or tablet. Today you’re going to do something slightly different, and configure a textbased mail client so that you can read your University email while using a terminal. The email
client we’re going to use is called Mutt, which is fairly simple to configure and straightforward
to use (according to its author, Michael Elkins, “All mail clients suck. This one just sucks less”).
There are plenty of other similarly lean text-based email clients , and you may at some point
want to check out Alpine as a sensible alternative to Mutt or for the historically-curious, Elm
(if you want a really hardcore terminal-mode experience of mail, look up Mailx ).
mutt
W
W
First, let’s confirm that Mutt is actually installed.
To see if Mutt is installed and is accessible to you, use the which command. Type:
which
$ which mutt
This should respond with /bin/mutt, telling us that the mutt command has been put in the
/bin directory on our system.
List the contents of /bin by typing
$ ls /bin
and notice that here we’re using ls to look at the contents of a directory other than the one
we’re currently in by passing the directory name as an argument. A whole load of things
should scroll past on the screen; most of them won’t mean anything to you right now, but
don’t worry, we’ll look at some of the important ones soon enough. Now that’s a lot of stuff to
look through, and depending on the size of your screen the command we’re looking for may
have scrolled off the top. So let’s try to narrow our results down a bit. Type:
$ ls /bin/ma*
and you should be given a much smaller list of things from the /bin directory; only those
starting with the letters ma. The asterisk symbol is interpreted as being a ‘wildcard’ that stands
for ‘anything of any length, including length zero’, so the command you’ve just typed means
‘list the contents of the /bin directory, showing only files that start with the letters ma and then
42
Introductory Labs
Using the Linux desktop in CS
are followed by zero or more other characters’ (notice that the man command that you used in
the last session is there amongst the results).
You could narrow this down even further by typing ls /bin/man*, in which case you’ll only
get files from /bin that start with the letters man. Note that if you leave off the asterisk from
your command, you’ll be asking for files that are called exactly ma or man, which isn’t what you
want here.
So far we’ve been getting you to do a fair amount of typing, and now we have to admit that
you’ve been typing a lot more than you actually need to (it’s good practice though, so we’re
not feeling too guilty at this stage). The default Linux command line has a feature similar to
autocomplete that you’ll have seen on web forms and in graphical tools, that saves you typing
full commands by suggesting possible alternatives.
Type ls / but don’t hit Enter, and instead press the Tab key twice. You’ll be shown a list of
sensible things that could follow what you’ve typed—in this case it’s the list of the contents of
the system’s root directory. Now type the letter u (so that the line you’ve typed so far should
read ls /u) and hit Tab once. This time your command will be expanded automatically to
ls /usr/ since that’s the only possible option. Press Tab twice now, and you’ll get shown the
contents of /usr/. Type b, and press Tab to expand the command to /usr/bin/, and then
press Enter to execute the command.
The autocomplete function you’re using here is more commonly called tab complete by Unix
users. If you press Tab once and there’s exactly one possible option that would autocomplete
what you’ve typed so far, then that option gets selected; if there are multiple possible things
that could complete your command, then Tab will complete as far as it it can, then pressing
Tab a second time shows you all of them, giving you the option to type another character or
two to narrow down the list. Learning to use this will save you a lot of typing, because not
only does it reduce the number of characters you type, it also helps you see the possibilities at
the same time. Very usefully, it also saves you from making lots of typing mistakes.
W
Here are some other handy command line tricks for you to try out (give them each a go now
so that you remember them for later):
• You can use the up and down arrow keys to cycle back and forth through the list of
commands you’ve typed previously.
• The left and right arrows do what you expect, and move the insertion point (often referred to as the cursor) back and forth. Pressing <ctrl>a will move you to the start of
the line, and <ctrl>e to the end of the line (much faster than moving backwards and
forwards character-by-character).
• <ctrl>c aborts the current line, so if you’ve typed a line of gibberish, don’t waste time
deleting it one character at at time, just <ctrl>c it!
• Typing history lists all the commands you’ve typed in the recent past, useful if you’ve
forgotten something.
• Pressing <ctrl>r allows you to retrieve a command from your history by typing part
of the line (e.g. if you searched for ‘whi’ now, it’ll probably find the ‘which mutt’ line
you typed a while back). Pressing <ctrl>r again steps through possible matches (if
there is more than one).
• Pressing <ctrl>t swaps the two characters before your cursor around. What, really?
Yes: you’ll be surprised how often you type characters in the wrong order!
43
Introductory Labs
Using the Linux desktop in CS
Breakout 2.1: File extensions
If you’ve mostly used Windows or macOS via a GUI, then you’re probably
used to files such as cheese.jpg, where you would interpret cheese as being
the file name and jpg as being the file extension. Some operating systems—
notably Windows—have the notion of a filename extension of a particular
number of characters built in; for example things ending with exe, bat or com mean that
they are executable files. In Unix, a file extension is merely a convention that’s not enforced
or meaningful to the operating system. So although it’s common to give files a suffix that
makes it easy for a human to guess what kind of file it is, Unix itself just treats these as
part of the file name. In fact, you can have multiple ‘file extensions’ in a name, to indicate
a nesting of file types. In the previous lab the file quake3.tar.gz is a tar archive that has
been gzipped, but the presence of the .tar and .gz parts are really just there to tell the
user how to treat the file.
W
Back to configuring your email client. Before we use mutt, we need to point it at the incoming
and outgoing email servers, and we’ll do this by creating a configuration file.
We’ve created a template file for you to get going with. Make sure you are in your home directory, then use the curl command as in the last lab session to fetch the template from
https://studentnet.cs.manchester.ac.uk/ugt/COMP10120/files/mutt-template
Remember, you’re going to need to use a switch argument to tell curl what it should call
the file it’s fetched: call it anything you like, but mutt-template is a perfectly good name (if
you’re feeling uncomfortable about a file that doesn’t have a file-extension, see Breakout 2.1
for more information). Let’s look at the file to see what’s in it. Type
$ less mutt-template
and you should see the following written to the screen:
#
# mutt configuration
#
# Change the following three lines to match your
# University of Manchester account details
set my_user_name="[email protected]"
set my_imap_server_name=[SERVERNAME].outlook.com
set realname = "Real Name"
# Change the following line to a different editor if you prefer.
set editor = "nano"
#####################################################
### Shouldn't need to change any more from here on ##
#####################################################
set imap_user = $my_user_name
set from = $my_user_name
set folder = "imaps://$my_imap_server_name:993"
set spoolfile = "+INBOX"
set smtp_url = "smtp://[email protected]$my_imap_server_name:587"
44
Introductory Labs
Using the Linux desktop in CS
Breakout 2.2: Spaced out filenames
Because of its roots in the early days of computing long before the advent
of graphical user interfaces, Unix filenames tend not to have spaces in them
because this conflicts with the use of a space to separate out commands and
their arguments. The Unix filesystem does allow spaces in filenames, but
you’ll have to use a technique called ‘escaping’ if you want to manipulate them from the
command line; this involves prefixing spaces in filenames with the backslash character \
to tell the command line not to interpret what follows the space as a new argument. For
example, a file called my diary.txt would be typed as my\ diary.txt. It’s a bit ugly,
but it works fine.
Breakout 2.3: Less is more
As we’ve mentioned before, many of Unix’s commands are plays on words,
puns, or jokes that seemed funny to the command’s creator at the time.
Though this gives Unix a rich historical background, it does rather obscure
the purpose of some commands. A prime example of this is the less command, used to page through text files that are too large to fit on a single screen without
scrolling.
Early versions of Unix included a command called more, written by Daniel Halbert from
University of California, Berkeley in 1978, which would display a page’s worth of text
before prompting the user to press the space bar in order to see more of the file. A more
sophisticated paging tool, called less on the jokey premise that ‘less is more’ was written
by Mark Nudelman in the mid 1980s, and is now used in preference to more in most Unix
systems, including Linux.
more
The less command is used to display textual content from files and other sources (if you want
to know why it has such an odd name, look at Breakout 2.3). One of less’s features is that
it ‘pages’ through text, so that if the file you are looking at won’t fit on one screen, pressing
the space key will move you on to the next ‘page’; you may notice that the man command you
used in the previous lab session actually used less to display the manual pages.
less
Don’t worry too much about the details of this file for now. If you’re already familiar with how
IMAP and SMTP work together to provide your email service, then you’ll be able to see what
the contents of this template mean; if you’re not, don’t worry, it’ll all be explained in detail
in the COMP18112 (Fundamentals of Distributed Systems) course in the second semester. We
just need to edit the file to contain your details rather than the fake ones in the template you’ve
just downloaded. But let’s play it safe: rather than editing the actual file you downloaded, just
in case you make a mistake, let’s first make a copy of the file in your home directory.
Quit less (using the same technique you used to quit the man command in the last lab session),
and then enter
$ cp mutt-template mutt-template-copy
45
Introductory Labs
Using the Linux desktop in CS
Did you type all of that? If so, you’ve wasted several precious key presses! You could have
typed cp mu, and then pressed Tab to expand it to cp mutt-template, and then do the same
thing again to create the start of the second argument, finally adding on the -copy bit yourself.
It’s a good habit to get into and will save you a lot of time over the next few years.
The basic form of the cp command takes two arguments, the first being the file you want to
copy, and the second being the name of the file that will be created. Confirm that there is
indeed a new file in your home directory using ls, and that its contents are what you expect
using less (how would you find out what else the cp command could do?).
cp
To modify the file, you’ll need to use a text editor. Type
$ nano mutt-template-copy
to invoke the nano editor. Although fairly basic, the nano editor has all the features you’ll
need to make these changes, and helpfully shows you the various keyboard shortcuts to do
particular things such as saving and quitting at the bottom of the screen (remember, the caret
symbol (^) is shorthand for ‘ctrl’, so ^X means ’<ctrl>X’).
Now use it to make the following changes:
• Edit the line that starts set my_user_name to include your University email address.
• Edit the line that starts set my_imap_server_name to include the server name that you
obtained from the Outlook client in My Manchester.
• Edit the line that starts set realname to include your real name, in whatever way you
want it to appear in outgoing emails. Please use your proper name here and not a funny
nickname.
When you’ve made the changes, write out the file to your filestore and quit back to the command line. Then use less to confirm that the file now looks exactly as you want it to.
Now, mutt expects the file containing its configuration information to have a particular name,
and that’s not mutt-template-copy, so we’ll need to do something about that. The Unix mv
command is used to rename files or directories (it’s short for ‘move’), so use that to change the
name of the file to .muttrc by typing, not forgetting the dot at the start of the second filename
$ mv mutt-template-copy .muttrc
mv may seem like an odd name for a command that is used to rename a file, but it actually has
a number of uses, including moving a file from one part of the file hierarchy to another. You’ll
see more examples of this in a later lab session.
Rather like cp, mv takes two arguments; but instead of making a copy of the file, mv just changes
the name of the file given as the first argument to that of the second.
Type ls to confirm that the file name has changed as you’d expect.
Oh. But it’s gone! Actually, no, it’s still there, it’s just hidden! There’s a Unix convention
that filenames starting with a full-stop symbol don’t appear when you type ls in its basic
form, because these are normally configuration files that you don’t need to see on a day to
day basis (the ‘rc’ part of the .muttrc name stands for resource configuration, another Unix
convention). So to see these files you’ll need to add an extra switch argument to ls. Use the
man command, with an appropriate argument, to find out what this switch is, and then use the
switch to confirm that the .muttrc file does indeed exist.
46
mv
Introductory Labs
Using the Linux desktop in CS
Using this switch on ls will reveal several other so-called dotfiles that have been lurking in
your home directory all along.
If you’re confident that you now have a file called .muttrc containing the correct configuration, you can now type mutt to start the program.
It should be reasonably clear how you use mutt to send and receive email; if you get stuck
there are plenty of online tutorials to help you out. Send yourself a test email to make sure
that everything is working, and when you’re confident you’ve mastered the basics of sending
and reading using this tool, quit mutt to get back to the command line. One thing you should
note is that mutt doesn’t have its own editor for composing emails, so will use nano unless
you change this to something else in the .muttrc file.
2.3
Browsing the Web
Although you will have experienced The Web so far as a highly graphical system, the technology that underpins it is for the most part text-based, and it is (just about!) possible to browse
web pages using a terminal-mode application. It might seem like an odd thing to do, but
there’s an important point to be made here, so bear with us.
Try browsing the School’s web pages using lynx by typing
lynx
$ lynx https://studentnet.cs.manchester.ac.uk
Rather like mutt, the lynx program has just about enough on-screen help for you to be able to
browse around a little without any additional instructions from us. You may find that when
you follow some links, nothing very much appears to have happened; but scroll right down
the page and you should see the content that you’re looking for.
You’ll probably find using lynx an unsatisfying experience: tolerable, and probably okay in
an emergency, but not how you’d ideally like to browse the web. And you might be wondering why we’ve even bothered to get you to try viewing the web through a text-only interface.
Apart from the absence of images and videos etc., the main difference between using something like lynx and a regular browser such as Chrome, Firefox, Safari or Internet Explorer, is
that you’ll notice that web pages have been made into much more linear affairs than when they
are rendered in a graphical environment. While you might expect to see the navigation links
neatly arranged on the left or top of the page with the main content prominently displayed in
the centre, seen through a purely textual interface it’s all one big stream of stuff, and it’s very
hard to distinguish between the navigation links and the main content.
Now consider what the web ‘looks’ like if you are visually impaired or blind and have to use a
screen-reader (a voice-synthesiser program that vocalises the text that’s on-screen) to interact
with your computer. Whereas a sighted person can easily cope with a two-dimensional layout
that allows you to be aware of multiple things at the same time (i.e. you can be reading the
main content of the page, but conscious of the fact that there’s a navigation bar on the left for
when you need it), if instead you are listening to a voice reading the contents of the page out
to you, it’s only possible to be hearing one thing at a time. And what’s more, you have to
remember what has been read out in the past in order to make sense of what you are hearing
now; you can’t just ‘flick back’ a paragraph or two by moving your eyes, instead you have to
instruct the screen reader to backtrack and re-read something. So the experience of using the
web if you are visually impaired has some things in common to interacting with web-pages
using lynx.
47
Introductory Labs
Using the Linux desktop in CS
You’ll soon be designing your own web-based systems as part of the Team Project in the later
stages of COMP10120; making them accessible to visually impaired readers is something you
should keep in mind. Try using lynx to browse some of your favourite websites, and you’ll
almost certainly find that the level of ‘accessibility’ on the Web varies considerably!
2.3.1
Pipes and Redirects
One of the fundamental philosophies of Unix—and one that is a sensible philosophy when
you’re building any computer system really—is that the operating system is composed from
lots of simple sub-systems, each of which performs one clearly defined task. To do something
more complex than any of the individual tools allows you to do on its own, you are expected
to combine components yourself. At the command line, Unix makes this quite simple, so let’s
give it a go.
First, use lynx to look at the BBC’s weather page at www.bbc.co.uk/weather and have a
quick browse around to get familiar with what it looks like. Then quit lynx and get back to
the command prompt before typing:
$ lynx -dump http://www.bbc.co.uk/weather
Note the addition of the -dump argument before the URL this time. Instead of running as an
interactive browser, lynx should have just output the text that it would have displayed for
that page to the screen, and then ended. Now, most of the text of the page will have scrolled
off the top of the screen, so let’s use the less command to allow us to page through lynx’s
output in a more controlled manner. Type:
$ lynx -dump http://www.bbc.co.uk/weather | less
Did you type all that? Hopefully not—remember you can use the up and down arrow keys to
get previous commands back at the interactive prompt, and then just modify or extend them
to save wearing out your fingers.
To explain what’s happened here, you’ll have to understand the concepts of standard in and
standard out, which are a neat and extremely powerful idea that is fundamental to the way
tools (and programs generally) work in a Unix environment.
Every Unix program has access to a number of ways of communicating with other parts of
the operating system. One, standard in, allows a stream of data to be read by the program;
another, called standard out, gives the program a way of producing text. By default, when
you execute things at the command prompt, the shell arranges for a program’s standard in to
be connected to whatever you type at the keyboard, and for its standard out to be connected to
whatever display you’re using at the time (this is a bit of an over simplification, but it’ll do for
now). It’s quite easy to arrange for standard in and standard out to be connected up differently
though, and that’s what you’ve just done.
The vertical bar ‘|’ before less is called the pipe symbol, and it is used to join the output of
one command to the input of another; so in this case we have connected the standard output
from lynx directly to the standard input of less. When less is invoked without a filename
argument, it expects to get its input from standard in.
As well as being able to join commands together, you can use the idea of manipulating standard in/out to create or consume files instead. Try:
48
Introductory Labs
Using the Linux desktop in CS
$ lynx -dump http://www.bbc.co.uk/weather > weather.txt
and then use ls to confirm that a file called weather.txt has been created, and use less
to look at its contents (which should be just the text from the weather web-page we’ve been
looking at already). Here the ‘>’ symbol redirects the standard out of the lynx command so
that instead of going to the screen it gets put into a named file.
To finish off this first contact with pipes and redirects, we’ll use a new command called grep
along with lynx to create a simple command of our own that tells you what the weather is like
in Manchester (there are very few labs with windows onto the outside world in the Kilburn
Building, so this may be more useful than you think!).
grep is a hugely powerful and useful utility, designed for searching through plain-text files.
Learning to master grep will take more time than we have in this lab, since you’ll have to
understand the idea of regular expressions to make full use of it (we’ll come to those in a later
lab). For now, we’ll use it in its very simplest form. Type:
$ grep BBC weather.txt
and you should see a list of all the lines from weather.txt that contain the word ‘BBC’. Use
less to have a look for other terms to ‘grep’ for (you might want to try something like ‘Sunny’
to give you a list of all the places where the weather is nice, for example).
Rather like less, if grep isn’t given the name of a file as its last command-line argument (in
this case we used weather.txt), it will operate on standard input instead of grepping through
a file (yes, it’s quite okay to use grep as a verb from now, no one will look at you funny). Use
this knowledge to join together lynx and grep so that the output is a single line describing the
weather in Manchester at the time we run the command. The output should look something
like:
[33]Manchester 22°C 72°F
As a final flourish, let’s create a new a way of accessing this new ‘weather in Manchester’ tool
that you’ve created. Type:
$ alias mankyweather="[YOUR COMMAND GOES HERE]"
replacing [YOUR COMMAND GOES HERE] with the full command line you created to display the Manchester weather, being careful not to introduce extra spaces around the equals
sign =. Then try typing
$ mankyweather
to see the result. Okay, so this probably won’t replace your favourite weather web page or
app, but it’s early days yet! Note that this alias will disappear once you exit the shell in which
you created this, for example when you logout and login again. We will see in a later lab how
to make such aliases permanent.
49
grep
Introductory Labs
Using the Linux desktop in CS
Figure 2.1
Scientific Linux’s default graphical user interface and window manager, GNOME 3. The
screen is almost empty but clicking on ‘Applications’ on the far left of the top menu bar opens
a menu of apps. Clicking on the ‘power’ icon on the far right gives the ‘log out’ option as
shown in Figure 2.2.
2.4
X Windows and GNOME
Next you’re going to start up one of Linux’s many graphical user interfaces. Type:
$ startx
You’ll see a chunk of text scroll up the screen briefly before being presented with something
that looks like the screenshots in Figures 2.1 and 2.2, although the background may look
slightly different.
Take a few minutes to explore the graphical environment. Even if you’ve never used Linux
before, you’ll probably find the general principles of this environment quite familiar: there are
icons on the desktop giving you access to the computer via a graphical file browser, and at
the top of the screen a menu-bar allows you to start various applications and utilities. The full
manual for this environment—which is called GNOME 3—is available online at
https://help.gnome.org/users/
but you’ll probably be able to work out everything you need to get you going by poking
around at the various buttons. Unlike the Raspberry Pi where you have complete control over
the operating system via the sudo command, the lab machines are configured so that you can’t
do any long-term damage to the setup. Apart from accidentally deleting your own files (and
right now you have very little important stuff to accidentally delete!), there’s nothing much
you can do that will cause problems, so feel free to explore a bit.
Perform the following tasks:
50
Introductory Labs
Using the Linux desktop in CS
Figure 2.2
Logging out from GNOME 3.
Breakout 2.4: GNOME and Mutter
It’s quite common to refer to GNOME as a ‘window manager’, but technically
it is much more than that; it’s actually a collection of tools, applications and
other programs that together form a graphical desktop environment. The
window manager component of GNOME 3 is called Mutter .
W
1. Find two different ways to start a terminal window.
2. Find two different ways to start the Firefox web-browser.
3. Use Firefox to visit the School UG home page: studentnet.cs.manchester.ac.uk/ugt/
4. Work out how to change the desktop theme and choose one you like.
5. Create a keyboard shortcut for starting Firefox, to provide a third way of starting it.
6. Find the Vector Graphics drawing application called Inkscape, and use it to draw a simple self-portrait. We just want you to spend a couple of minutes getting used to the kind
of things that Inkscape can do—it will be very useful later in your degree programme
when you’re going to need to draw diagrams to go in your reports. For now any old
doodle will do quite nicely (look at what Steve drew in Figure 2.3, we’re really not setting the bar very high at all here!). Make sure you save this file, we’re going to need it
later.
W
7. Figure out how to log out of the graphical environment.
If you’ve completed step 7 you should now be back at the command prompt where you typed
startx a little while back. Before returning to the graphical environment where you’ll spend
most of your time, it’s important to understand how the graphical interface you’ve just been startx
using works as part of the Unix operating system.
If you remember back to the first Raspberry Pi lab, we pointed out that the shell (bash) that
you’re using to interpret commands is ‘just a program’ that happens to interpret input from
the user, execute commands, and display the results. The graphical environment you’ve just
51
bash
Introductory Labs
Using the Linux desktop in CS
Figure 2.3
This is a picture of Mister Noodle drawn by Steve using Inkscape. It took about two minutes,
though in reality had he spent any more time on it there would be no obvious improvement in
the quality of the artwork.
Breakout 2.5: Inkscape and GIMP: Vector and bitmap graphics
Inkscape is a vector graphics drawing package; it allows you to draw and manipulate different shapes to create pictures and diagrams. It is ideal for drawing diagrams and figures. When you’re using a tool such as Inkscape you’re
manipulating geometrical shapes such as points, lines and curves. One of
the big advantages of this approach is that images look the same regardless of what magnification you use. In these notes we’ve tried where possible to use vector images, so
you should be able to zoom into the pages on the electronic version without seeing any
‘pixellation’ happening. Some figures contain a mixture of vector and bitmap graphics;
for example, zoom into Figure 2.1 and you’ll see that the image of the desktop itself starts
to become jagged (because it’s a bitmap), whereas the red boxes and numbers stay nice
and crisp at any magnification (because they’re vectors).
GIMP, on the other hand, is a bitmap based image manipulation package; it treats images
as being made up of lots of coloured dots (pixels). GIMP is great for editing photographs
and creating certain types of artwork, but it’s not hugely useful for drawing diagrams.
It’s worth understanding the pros and cons of these two different approaches to graphics,
it’ll save you a lot of heartache later on and you’ll end up creating more professional
looking figures in your documents. The Wikipedia page on vector graphics provides a
good explanation of the different approaches.
W
used is similar—just a program (or actually, collection of programs) that runs on the operating
system.
But what do we mean by ‘execute commands’? You’ve probably got the hang of the fact by
now that most of the things that happen in Unix are just programs stored somewhere on the
file system (remember, you found some of them in the /bin directory). When you press Enter
at a shell prompt, the shell checks that what you’ve typed has a valid syntax, and then starts
up a new process in which that program executes. The process is mostly independent of
the shell program that started it, gets on with doing whatever it was designed to do, and
when it finishes it tells the shell that it’s done, and the shell gives you another prompt for the
next instruction. Something very similar happens when you run the startx command: the
52
Introductory Labs
Using the Linux desktop in CS
graphical environment starts executing, and when you select the ‘log out’ option, it returns you
back to the shell so you can issue another command. Notice that you haven’t been ‘logged out’
of Linux, but rather just out of the graphical environment – we’ll show you how to configure
things so that ‘log out’ in the GUI really does log you out in a little while. But first, let’s take a
step back now and look at what the startx command has actually done.
2.5
X Windows
Unlike macOS and Windows and most mobile operating systems, Linux doesn’t really have a
graphical windowing environment ‘built in’; what you’ve seen just now is a series of programs
that co-operate with one another to create the familiar WIMP environment (if you don’t know
what WIMP means yet, go back and read Breakout 1.1 from earlier in these notes).
User Applications
User
Window Manager Configuration
Window Manager
X Server
Unix / Linux
Graphics Drivers
Graphics Hardware
Graphics ‘Stack’
Hardware
Figure 2.4
The layered structure of Linux’s graphical system, with software nearest to the underlying
hardware at the bottom, and software closest to the user at the top.
When you ran Quake and the snake game on the Pi in the previous lab, these programs took
direct control of the graphics subsystem in order to display the game. The startx command
runs a system called X Windows , which also takes control of the computer’s graphics system,
but on its own doesn’t really do anything very exciting apart from allow other programs to
then share the display. Along with X Windows, another system called a Window Manager
was started, and this is what you see drawing the buttons and menus and window controls
for the graphical user interface. We’ll look at how X Windows really works in one of the
forthcoming COMP10120 lectures, and you’ll explore some aspects of the architecture of X
Windows in a lot more detail in COMP18112 (Fundamentals of Distributed Systems) in the
second semester. For now, it’s enough to understand that there are two things going on here:
first the X Windows system is running that allows stuff to be drawn to regions of the screen;
and second the Window Manager which is doing all the WIMPy stuff like providing all the
controls that allow windows to be moved and resized.
W
W
53
Introductory Labs
2.6
Using the Linux desktop in CS
Window Managers
One of the interesting effects of the X architecture, shown in Figure 2.4, is that it separates
out the system that draws stuff onto the screen from the one that deals with creating buttons,
sliders and windows, and enables you to choose a window manager that best suits the way
you work; some people like ‘rich’ environments like GNOME, whereas others like ‘lean’ cutdown window managers.
The startx command can be used to fire up window managers other than GNOME, but the
syntax used for doing this varies quite a lot from one Linux distribution to another, and in the
case of the version of Scientific Linux we’re using, its behaviour is a bit confusing. To make it a
little easier for you to experiment with different window managers, we’ve provided you with
a bespoke command csstartx that makes things a bit simpler. Because this is a program that
we’ve added outselves to the Linux distribution, we’ve followed the convention of not putting
it in one of the system’s own directories of commands (such as /usr/bin), which means that
it won’t get found automatically in the way that other commands you’ve used so far will, so
for now you’ll have to explicitly type its full absolute path name, and we’ll show you how to
modify this behaviour shortly.
Type:
$ /opt/teaching/bin/csstartx startkde
and you should find that a different graphical desktop environment, KDE, starts up. Experiment with this for a minute or two just to get a feel for what it’s like, and then quit back to the
command-line prompt.
As well as GNOME and KDE, which both follow fairly similar interaction paradigms to the
graphical environments of other operating systems, there are many alternative graphical interfaces for Linux.
Use the table that follows to explore some of these by using the value from the ‘Command’
column as the first command-line argument to csstartx instead of startkde. In each window
manager make sure you figure out how to create a terminal window, so you can get some work
done!
Name
Command
Description
Fvwm
fvwm
AnotherLevelUp
ALU
Fluxbox
fluxbox
Openbox
openbox
Awesome
awesome
A lean window manager with virtual desktops Hint: Click the
left mouse button.
A customised version of fvwm developed here in CS by John,
and still his favourite desktop environment (may contain bright
colours). Hint: Click the left mouse button.
A lean but highly customisable window manager. Hint: Click
the right mouse button.
Similar to Fluxbox; lean and highly configurable. Hint: Click the
right mouse button.
A very very lean tiling window manager. Hint: Right click on
the black background. To exit press windows-shift-Q.
As you become more familiar with Unix principles, keep the fact that you can easily swap
window managers in mind. Most likely there will come a point where the graphical niceties of
environments like GNOME become unnecessary, and perhaps even a distraction from getting
work done, and you might find that a slimmed down window manager suits you better as a
more experienced ‘power user’. For the rest of these exercises, though, we’ll assume you’re
54
Introductory Labs
Using the Linux desktop in CS
Breakout 2.6: Tiling window managers
It’s likely that you are so familiar with the way that windows are managed on
operating systems like Windows or macOS that you’ve never really thought
about alternatives. Awesome and Xmonad are very minimalist window managers, probably quite unlike anything you’ve used before. Most WIMP environments that you’ll have used so far make you the user responsible for the position
and size/shape of the windows that represent tools and applications on the desktop. The
upside of this is that you can arrange things exactly as you like them; the downside is that
you probably use up an amount of time doing that arrangement, and often end up with a
layout that wastes some of the desktop’s usable space. Awesome is what’s called a ‘tiling’
window manager; instead of giving you detailed control over the exact shape of windows,
it lays them out on the screen in one of several configurations designed to maximise the
use of space. Because you can’t drag or resize windows with the mouse, there’s no need
for the usual window decorations, so you save a few pixels this way too.
There’s no doubt that these window managers are at the hard-core end of the window
manager spectrum, and are designed for experienced users that need a very large numbers
of windows open at once, probably spread over several physical displays (as in Figure 2.5).
Apart from the ‘tiling’ aspect, it gives you virtually no visual cues as to how to perform
various actions, most of which are designed to be invoked via keyboard shortcuts (in fact,
Awesome is designed so that you can use all of its features without needing to touch the
mouse at all.) Once you’ve remembered all the keyboard combinations, using a window
manager like Awesome or Xmonad can be extremely efficient in terms of time and screenspace.
using GNOME (if you’re confident enough to use something else, then translating our instructions to make sense in whatever environment you’ve chosen won’t be too big a problem).
2.7
Starting a graphical environment automatically
Now, if you’re going to use the graphical environment as your primary interface (and, as the
jobs we ask you to do get more complex, you’re going to need to!), you may find it slightly
annoying to have to log into a lab machine, start the graphical environment, log out of the
graphical environment when you’re done and then remember to also log out of the terminal environment before you leave (because if you don’t do this, other people will have access to your account!).
Back in the previous lab session we explained that when you log into a Unix machine, an
interactive shell is created for you to run commands from, and that the shell is ‘just a program’
like any other that just happens to be the one nominated to be the first thing to run when you
log in.
What about nominating the graphical environment as the first thing to run instead? We’ve already pointed out that it’s ‘just a program’ too, so that should be okay? Although in theory it’s
possible to do this, in practice it’s a bad idea: shells are quite simple self contained programs,
whereas graphical environments are much more complex systems relying on hundreds of files
to be installed in the right places in order to work. You certainly don’t want to set your system
up in a way that if the graphical environment gets damaged in some way you can’t log in at
all.
55
Introductory Labs
Using the Linux desktop in CS
Figure 2.5
The Awesome window manager showing around 20 windows tiled over 6 physical displays.
Reproduced from awesome.naquadah.org with kind permission of Julien Danjou, one of
Awesome’s primary authors.
Instead we’ll show you a rather safer way to get the GUI to fire up when you log in.
When you first run the bash shell on login, it looks for a file in your home directory called
.bash_profile and executes any commands it finds in there as though you’d typed them at
the keyboard; so this is a useful place to put the command to start the graphical environment.
Use the ls -a command to confirm that there’s already a file in your home directory called
.bash_profile, and then use less to look at its contents (There should also now be one called
.bash_history, take a look at it and it should become obvious how the history command,
and the ‘reverse search’ function you used earlier work).
.bash_profile should look something like this:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/.local/bin:$HOME/bin
export PATH
though don’t worry if there are slight differences. We’ll come back to what these instructions
mean in a later lab.
Start up the nano editor, and use it to add the following as a new line at the end of your
.bash_profile:
56
nano
Introductory Labs
Using the Linux desktop in CS
/opt/teaching/bin/csstartx
Use less to check that this line has now been added to your file.
If you’ve already decided you want to try out something other than GNOME as your default
window manager, add the appropriate command from the table after csstartx.
Now log out, and log back in again; you should find that the graphical environment fires up
automatically.
Next, quit out of whichever graphical environment you’ve chosen and. . . oh dear, you’re back
at the command prompt, rather than logged out completely.
Now this could be really confusing; you’ve created a situation where you don’t have to start
the graphical environment up manually, but you do have to remember to log out twice when
you’ve finished using it, once from the GUI and again from the console prompt. Yuck.
Fortunately there’s a relatively easy fix for this.
At the command prompt, type the following:
$ exec man ls
You should find that the man command has done exactly what you normally would expect,
but that instead of returning you to the command prompt when you’ve finished reading the
man page, you’ve been unceremoniously logged out! Log back in again (sorry about that).
The exec command changes the way in which the shell deals with whatever command follows it. Instead of starting a new process in which to run your command and waiting in the
background for that command to complete, the shell gives up the process in which it itself is
running, and hands it over to the command you’ve issued. So when that command finishes,
there is no shell to come back to. And because in this case the shell was the first program that
got run when you logged in, the Unix system logs you out since there’s nothing else you can
do.
Experiment by running exec /opt/teaching/bin/csstartx and then logging out of the
graphical environment as you did a moment ago; this time you should find that you’ve automatically been logged out of the console too.
Use the nano editor to alter the line you’ve just added to .bash_profile so that it now reads
exec /opt/teaching/bin/csstartx
Now log out, either by typing logout, or pressing <ctrl>d to tell the shell that its input
has ended. Now log back in again; if all has gone to plan then you should see the graphical
environment fire up automatically; and when you quit the graphical environment, you should
be returned to the Linux login prompt.
Hurray!
Before we leave this section on graphical environments, there’s one quirk that we’ve got to deal
with to avoid causing problems later on. As we said earlier, instructions in the .bash_profile
file get executed when you log in to a Unix machine
This works fine when you login directly to a PC from the console, but will cause problems if
you login remotely from another machine, as you will in the next lab. So we need to arrange
things so that we only try to start up the graphical environment if the user has logged in from
the console, and not via a remote connection.
57
exec
Introductory Labs
Using the Linux desktop in CS
Carefully replace the line you’ve just added containing csstartx at the end of .bash_profile
with the lines:
case $(tty) in
/dev/tty1) exec /opt/teaching/bin/csstartx
esac
Note that the character after /dev/tty is the digit 1 and not the letter l.
This piece of ‘shell script’ reads something like ‘in the case where the terminal device being
used is the physical console, then execute the graphical environment’. We won’t explain the
exact meaning of this piece of code now but will do in a lecture; for now just make sure you’ve
typed it exactly as written here.
You should now log out and login again to check that the graphical environment starts up,
shuts down and logs you out as expected.
If you’ve mistyped any of the lines in .bash_profile you may find that when you try to log
in, you’re instantly logged out. Don’t panic and call for some help from the lab staff; it’s a
common mistake and an easy one to rectify!
2.8
ARCADE
We would now like you to register your access to the ARCADE server. ARCADE is the laboratory management system we use to administer coursework marks and deadlines, etc.. You
can use the client query program to look up your details, laboratory timetables, marks, and so
on, throughout the year. It is recommended you do this fairly regularly, if only to check that
mistakes have not been made in your marks! You need to register with ARCADE before any
of your lab work can be submitted, so it is much better to do it now than wait until your first
deadline!
In a terminal window, run the command /opt/teaching/bin/arcade; after a short pause, a
new window will pop up. In the large text box you should find a message telling you that you
are not yet authenticated, and that you have just been sent an email. If this is so, then quit the
program, read the email you have just been sent by the ARCADE server, and carefully follow
the instructions in it. Now start the ARCADE Query client again, and it should now connect
you to the server. If this works, then your access is set up; if it doesn’t then check you’ve
followed the instructions precisely. If it still doesn’t work then, as always, ask for help; it is
very important that this registration process is completed.
Explore the various queries of the client, and familiarise yourself with the the user interface.
Check that your registration details are correct. Feel free to ask for explanation if it is not
obvious to you.
2.9
Text Editors
A great deal of the lab work you will be doing over your time here will involve you creating
text files of various kinds, often source files in a programming language such as Java , PHP
or C , or HTML files for use on the web. There are specialist tools called Integrated Development Environments or IDEs that can be used for programming; you will meet these later in
your programme. However, for many purposes, the simplest, and best, tool for creating such
W
W
W
W
W
58
Introductory Labs
Using the Linux desktop in CS
Figure 2.6
gedit
(a) kate
(b) emacs
Figure 2.7
Other editors
files is a simple text editor. You have already met one such tool, nano, which is fine for work at
the console or quick modifications of existing files, but for more extensive work an editor that
takes advantage of X’s graphical capabilities is more appropriate.
The Linux environment in which you will be working offers many such editors, including the
default GNOME editor gedit, the KDE editor kate and the grand daddy of all editors, emacs.
These three are illustrated in Figures 2.6 and 2.7. They are all shown ready to edit a Java source
file; note that they all use the fact that this is Java source to highlight key words within the text.
When you have some free time, please do experiment with some of the text editors available
and find one that you like; in the meantime you should probably use gedit.
59
Introductory Labs
2.10
Using the Linux desktop in CS
Shell environment variables
When you used the csstartx command, you had to prefix these with their full pathname,
which is /opt/teaching/bin/. The directory /opt/teaching/bin is a place where we keep
lots of useful teaching related tools, so it would be useful if you didn’t have to type it every
time you want to use a program from there; luckily there’s a way of doing this. When you
type a command on the command line, the shell looks for a program of that name in a number
of places. These places are determined by the value of a shell environment variable called
PATH. You can see what its current value is by using the command
W
$ echo $PATH
This will show a long list of directories, separated by colons (:).
There are many other shell variables already set for you, they can be seen by running the shell
command set (do this now). How do you stop the output scrolling off the screen? Most of
these variables won’t make much sense to you at the moment, but among them are HOME, PWD
and HOSTNAME; you can check their values using echo. What do think their values represent?
You can set the value of a shell variable at the command line, for example type:
$ MYVAR=42
$ echo $MYVAR
Note that there should be no spaces either side of the = sign and that the variable’s name is
MYVAR and its value is obtained by using $MYVAR. If a variable is given a value on the command line in a terminal window like this its value is only available in the shell running in that
window.
In order to be able to start the ARCADE client by typing arcade rather than by using the full
pathname /opt/teaching/bin/arcade we need to modify the PATH variable to include the
directory /opt/teaching/bin. We can do this on the command line by typing
$ PATH=$PATH:/opt/teaching/bin
This can be read (and you will see this over and over again in programming languages) as
’find the value of the right hand side of the = and give (or assign) that value to the variable
on the left hand side’. So this takes the current value of PATH and adds :/opt/teaching/bin
on the end. After you’ve done this you can type arcade in your terminal window and the
ARCADE client should start. Just exit it cleanly and return to the shell.
If you now start another terminal window and type arcade, what happens and why?
The way to make the change permanent is to modify your .bash_profile file. While we are
doing this we will also add two more useful directories to our PATH, namely /opt/common/bin
and /opt/scripts, which are also shared directories containing useful local stuff.
Use gedit to modify .bash_profile by adding the following line immediately before the existing line starting with PATH.
PATH=$PATH:/opt/teaching/bin:/opt/common/bin:/opt/scripts
This won’t have any effect until you logout and login again. So do that now and try starting
arcade. Run echo $PATH and you will see the new value, which contains your own bin
directory, now preceded by the three /opt directories.
60
set
Introductory Labs
2.11
Using the Linux desktop in CS
Configuring Thunderbird
Rather than explain the Thunderbird configuration here we refer you to an illustrated guide to
this process, which you can find at https://wiki.cs.manchester.ac.uk/index.php/
How_to_set_up_Office_365_Mail_in_Thunderbird, written by a fellow student.
Follow all three steps in the process described in this document.
Once your Inbox appears in Thunderbird, using it to compose and send email should be fairly
self-explanatory, but if you’re stuck there are plenty of Thunderbird tutorials available on the
web.
2.12
That’s all for now
If you have reached this point before the end of the lab you may have gone too fast so please
go back and review what you have done. You will be using many of the ideas we’ve just met
in later labs, so it’s important to understand them. When you are sure you have completed the
work for this session, please tell the lab supervisor.
61
Intro Lab Session 3
Pi power
Contents
3.1
3.2
3.3
3.4
3.5
3.6
3.7
The LXDE graphical environment . . . . . . .
Configure mutt again using scp and ssh . . .
3.2.1 Emailing your tutor . . . . . . . . . . .
X Windows again . . . . . . . . . . . . . . . . .
A Simple Web Server . . . . . . . . . . . . . .
3.4.1 A slightly more interesting web page .
Headless Pi . . . . . . . . . . . . . . . . . . . .
3.5.1 Setting up Apache, a proper web server
3.5.2 Permissions, users and groups . . . . .
3.5.3 Back to that webserver . . . . . . . . . .
Shutting down gracefully . . . . . . . . . . . .
Finishing up . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
62
63
66
66
67
70
71
73
73
75
78
78
These notes are available online at
syllabus.cs.manchester.ac.uk/ugt/COMP10120/labscripts/intro3.pdf
We suggest you use the online version so that you can follow web links.
So far you’ve used your Pi and the lab PCs separately, and hopefully you’ve come to understand that they are both essentially the same kind of machine; they both run variations of the
same operating system, and the principles you learn using one for the most part apply to the
other. In the case of the Pi, you have complete control of the device as a superuser, so can
do absolutely what you like to it; in the case of the lab machines you have access to much
more powerful hardware, but more restricted access to the filestore and operating system for
reasons of security and privacy.
Today, we’ll be getting your Pi and a desktop PC to communicate with one another, to reinforce the similarities between these setups, and to expose you to some of the principles of
networking and remote access.
3.1
The LXDE graphical environment
Connect your Pi up to the monitor, keyboard, mouse, network and power supply as before,
and log in (remembering this time to use whatever password you set on the Pi rather than
September 8, 2017
62
Introductory Labs
Pi power
Breakout 3.1: LXDE isn’t a window manager either
Rather like GNOME, LXDE is a technically a collection of desktop tools rather
than a window manager as such. LXDE uses the openbox window manager,
and GTK+ , which was developed as part of the GIMP project to draw the
buttons, sliders and other graphical controls. LXDE is the default graphical environment for several ‘lean’ or ‘low power’ Linux distributions such as Knoppix ,
Lubuntu and of course the Pi’s operating system, Raspbian .
W
W
W
W
W
W
your University password, and the username ‘pi’). At the console, type:
$ startx
to start up X Windows and the Pi’s default window manager, LXDE, which appear moments
later looking like the screenshot in Figure 3.1.
LXDE (the ‘Lightweight X11 Desktop Environment’) is designed to be a lean, fast desktop
environment, which makes it ideally suited for the Pi’s modest CPU. Although rather less rich
in features and ‘eyecandy’ than GNOME, LXDE is a fully functioning environment that has all
the features you will need for operating and programming the Pi.
Up at the top of the screen you will see controls that give you access to various applications,
tools and system preferences. On the panel’s right are a CPU meter and a clock. On the desktop
itself is a shortcut to the Wastebasket, which is similar to the Recycle Bin on Windows and the
Trash on macOS.
Spend a few minutes exploring the GUI. You may find that you’re double-clicking on things
that only need a single click, and vice versa, and may find that things aren’t quite where you
expect them to be—but rather than dismissing LXDE as being crude, embrace the differences;
you may well find that you come to prefer its ‘no frills’ approach to window management
over that of richer, heavier-weight environments such as GNOME. LXDE and other slimmeddown graphical environments consume considerably fewer CPU cycles and hence less power
than their richer counterparts, and while this isn’t an issue when you’re running on a mainspowered desktop machine with a reasonably beefy graphics card such as the lab PC, this can
be a serious issue for devices running off batteries (and it does mean of course that LXDE is
rather more environmentally friendly!)
3.2
Configure mutt again using scp and ssh
Once you’ve found your way around LXDE, fire up a terminal so that you can configure your
Pi to read your University email using Mutt. Unlike the lab machines, the mutt command isn’t
installed by default on the Pi, so you’ll need to do that yourself using:
$ sudo apt-get install mutt
Once the install has completed, you’ll need to adjust Mutt’s settings so that they once again
point at your University email account. You could do this by following the instructions in the
previous session’s script again, but there’s a much easier way: let’s just copy the configuration
file you created on the desktop PC last time, over to the Pi.
63
Introductory Labs
Pi power
Figure 3.1
The Pi’s default window manager is called LXDE.
Breakout 3.2: Unix hostnames
A machine’s hostname identifies it on a network in a way that’s usually a bit
more human-readable than its IP address. There are various ways of finding
out a machine’s hostname:
• If you haven’t logged into the PC and can see its screen, then it should be showing
the hostname such as E-C07KILF3101: before the login prompt.
• If you’re already logged in to Unix, but have not started a window manager, your
console prompt will be something like [[email protected] ~]$ (where
mrnoodle would be replaced by your own username, of course).
• If you are logged in to the PC and inside a window manager, open a terminal window. It should show you the command line prompt, as above. You could also type
echo $HOSTNAME, or use the hostname command.
hostname
First you need to check that you still have the .muttrc configuration file in your home filestore
of your Computer Science account. You could unplug all the cables from the Pi, connect them
back into the desktop PC and check that way, but that’s no fun (especially because we’d then
have to reverse it all to do the next bit of the exercise). But you don’t need to do that: you can
check remotely.
Find the hostname of the lab PC on your desk: there should be a sticker on both the PC itself
and the monitor with a name such as E-C07KILF3101. If for some reason there isn’t a sticker,
Breakout 3.2 describes several other ways to find a Unix machine’s hostname.
Once you’ve got hold of the PC’s hostname, you’re going to use a Secure Shell to connect
from the Pi to the PC, allowing you to type commands on the Pi that will be executed reW
64
Introductory Labs
Pi power
motely via a shell that’s running on the PC. Open a terminal window on the Pi and issue this
command:
ssh
$ ssh [USERNAME]@[HOSTNAME].cs.man.ac.uk
replacing [USERNAME] with your University username, and [HOSTNAME] with the name
of the PC in front of you. You’ll need to enter your University password, and will most likely
be presented with text something similar to this:
The authenticity of host 'E-C07KILF3101 (130.88.197.112)' can't be
established.
RSA key fingerprint is 20:6d:2d:90:5e:8f:9f:19:39:70:ce:48:a6:93:ec:4c.
Are you sure you want to continue connecting (yes/no)?
Type yes (and hit enter) in response to the question. You should then be given a command
prompt. You’ll learn more about what this message actually means later in your programme,
but for now just treat it as something that happens the first time you try to connect to a particular machine. Notice that this command prompt no longer says [email protected], but rather
has the name of the machine you’ve just remotely logged into. If your prompt still includes
[email protected], then something hasn’t worked: you probably got the PC hostname wrong,
or mistyped your University username or password, so just try again.
Type ls -a to confirm that your .muttrc file is still where you expect it to be, and if all is
well then press <ctrl>d to log out of the remote shell you just started, and you will return
to the shell running locally on your Pi (you’ll see the command prompt change back to being
[email protected] again). Now we know that the file we want is there, we need to copy it
from your Computer Science filestore onto your Pi’s local filestore.
To do this, we’re going to use the scp (Secure Copy) command, which in some ways behaves
like cp, but allows us to copy files between machines.
Like cp, the scp command in its basic form takes two arguments, the first is the name of the
source file (the one you want to copy), and the second is the name of the destination file (the
one you want to create). The difference with scp is that either (or less commonly, both) of
these files can be on a remote machine, which means that you need to provide the command
with enough information about the location of the remote file in terms of the hostname and file
system, and any login details necessary to get at it. The syntax for providing this information
is:
[USERNAME]@[HOSTNAME]:[FILEPATH]
So for example, if you wanted to retrieve a file called cheese.jpg from the home directory of
a user called mrnoodle that was stored on a machine with the hostname mypc.example.com,
and you wanted the local copy of the file to be called mycheese.jpg the command would be:
$ scp [email protected]:cheese.jpg mycheese.jpg
Then, supposing you had edited the file mycheese.jpg on your local machine and wanted to
put the file back into the home directory of the mrnoodle account on the remote machine—but
under a different name so as not to over-write the original—you would use the command:
$ scp mycheese.jpg [email protected]:newcheese.jpg
65
scp
Introductory Labs
Pi power
We’re not exactly sure why MrNoodle and cheese feature quite so prominently in this lab
either, just go with the flow. To summarise the behaviour of scp: if you prefix either or both
of the source or destination files with the pattern [USERNAME]@[HOSTNAME]: then you are
referring to a file on a remote machine, otherwise you are referring to a local file in the same
way that you would with a regular cp command.
Now use your new-found knowledge of scp to copy the .muttrc file from your Computer
Science account onto your Pi. You could use the hostname of the PC you’re sitting at as the remote host, or alternatively you could use a server called kilburn.cs.manchester.ac.uk
which is also set up to be able to see your Computer Science filestore. In fact, you could use the
hostname of any of the PCs in this lab, because your Computer Science filestore is accessible
to them all—but it’s probably antisocial to use a machine that someone else is sitting at, so for
now stick to using the one in front of you, or kilburn.cs.manchester.ac.uk.
Conveniently, there’s nothing in the .muttrc file that is specific to the Computer Science account setup, so you can use it as-is for Mutt on the Pi (as usual, if you get stuck ask for help.)
Check that the file has copied over successfully using less, and then start up mutt from a
terminal. If everything has gone to plan, you should now be able to read and compose emails
on your Pi. You can of course install other mail clients if you want to; there is a slimmed-down
version of Thunderbird for the Pi called Icedove (yes, yet another play on words), or a much
leaner graphical client called Claws Mail (which, if you want to, can be installed using sudo
apt-get install claws-mail). Remember, though, that the memory-card we’ve given you
for your Pi is fairly small, so you probably don’t want to clutter it up with unnecessary packages, and you should find that Mutt is perfectly okay for sending and reading the occasional
email.
3.2.1
Emailing your tutor
To test that you’ve sucessfully set mutt up on the Pi, use it to send a friendly email to your
personal tutor to tell him or her that you’ve reached this point of the lab (your personal tutor
will be the person you met last week for lunch with your tutor group; don’t email whoever
it is that’s running this lab unless they also happen to be your personal tutor). If you’ve not
figured out your tutor’s email address yet, you can find it using the Chromium browser at
http://www.cs.manchester.ac.uk/about-us/staff/
3.3
X Windows again
As we mentioned before, the X Windows system is a powerful system, and although it was
designed a long time ago (around 1984), it was in many ways way ahead of its time (rather
like the design of Unix itself.)
Remember that the GUI you’re now using on the Pi consists of two systems working together:
X Windows (which amongst other things gives software access to the display hardware), and
the Window Manager / Desktop environment (in this case, LXDE) that provides the WIMPstyle features such as movable windows and clickable controls. The X Windows system operates as a Client/Server architecture, where the server part does the drawing of stuff onto the
screen, and clients request that things be drawn. One of the really nice features of X Windows
is that it doesn’t care too much about where the requests to draw things come from. Typically
they come from processes that are running on the same computer as the X Server, but this need
not be the case as you’re about to demonstrate.
66
Introductory Labs
Pi power
Log back in to the lab PC using the ssh command, but this time include a -X switch before
your username, like:
ssh
$ ssh -X [USERNAME]@[HOSTNAME]
The -X switch (note that it’s an uppercase X) tells the ssh program to send any graphics instructions generated on the remote system back through the network to the X Server running
on the local machine.
Confirm that you are indeed logged into your Computer Science account by checking the
command prompt and using ls to make sure the files in your home directory are the ones
you’d expect (or use one of the techniques described in Breakout 3.2 to check the hostname),
and then type:
$ xeyes
Googly eyes that follow the mouse! What’s not to like? Well, okay, perhaps not hugely exciting in itself, but what’s actually happening here is rather interesting and quite sophisticated.
xeyes
The xeyes program is running on the remote machine (the desktop PC); but the instructions to
draw its graphical output are being forwarded over the secure shell connection you’ve made
from the Pi to the remote machine, so that the Pi’s X Windows system receives them. Make sure
that the terminal window you used to start xeyes is the active window, then press <ctrl>c
xterm
to quit xeyes, and instead try running xterm. You should see a new terminal window appear
on your Pi’s screen (which probably looks slightly different to the terminal you launched on
the Pi a moment ago; it does essentially the same thing though). This X Terminal, rather like
xeyes, is actually running on the desktop machine—only its graphical representation is appearing on your Pi (if you use ls in that terminal, you’ll see that its your Computer Science
account that’s visible, rather than your Pi’s filestore and you can confirm this another way
using the hostname command). Look at Figures 3.2 and 3.3 for a diagrammatic representation
of what’s just happened. Now exit this X Terminal by typing <ctrl>d in it.
hostname
W
3.4
A Simple Web Server
This next exercise involves setting up a simple web server on the Pi, but before we can do that
you’ll need to create some basic web pages to display.
Start up a terminal on your Pi, and use the mkdir command to create a directory called
htmlexample1 in your home directory, and in that directory, use nano to create a file called
index.html with the following content:
mkdir
<html>
<body>
Hello World!
</body>
</html>
From within that directory, run the command:
$ python -m SimpleHTTPServer
python
67
Introductory Labs
Pi power
2
X Server
1
xeyes
Raspberry Pi
Figure 3.2
In Unix, when you run a program such as xeyes on your local machine, it doesn’t draw
directly to the screen, but instead communicates with an X Server that by default is running
on the same machine. In our example, the xeyes program 1 connects to its local X Server
2 , and asks it to draw a window containing two ellipses to represent eyeballs, and then does
some calculations to work out where to draw the two smaller ellipses to represent the pupils
of the googly eyes so that they follow the mouse pointer. The X Server then communicates
with the graphics hardware of the local machine in order to make things appear on the display
that you see as a user.
68
Introductory Labs
Pi power
4
X Server
3
2
2
Secure Shell
xeyes
1
Raspberry Pi
Desktop PC
Figure 3.3
One of the powerful features of the X Windows system is that the program generating graphical output, and the display on which the graphical output appears need not be on the same
physical machine. In this example, we’ve used a Secure Shell connection from the Pi 1 to
make a connection to the desktop PC, and have used the -X option to ask that any graphical
instructions for the X Windows system get routed back through that connection. We then
start the xeyes program on the desktop PC. Now although the calculations to draw the googly
eyes are being done on the remote PC, the instructions to draw ellipses are sent back via
the ssh connection to the Pi 2 , and are 3 routed to the X Server that’s running on the Pi.
As before, the X Server 4 interprets these instructions (not caring that they originated on
another machine), and draws the eyes on the display that’s physically connected to the Pi.
69
Introductory Labs
Pi power
which starts a very basic Web Server and then use Chromium to browse to the following URL:
http://localhost:8000
If your browser displays a page saying ‘Hello World’, pat yourself on the back—you’ve just
created a web page and set up a simple web server to host it. The URL you used to view this
page may look a bit odd compared with others you have seen. The http:// part you’ll nodoubt be familiar with from other web-addresses that you’ve seen; the localhost part is a
convention that means ‘this machine’. The section of the URL that follows localhost may
be even less familiar: this is the port (for now just think of this as a kind of communication
channel) on which the simple web-server that you’ve set up is serving web pages; by default
web browsers expect servers to use port 80, but the python -m SimpleHTTPServer command
you used here defaults to port 8000, so we had to add that to the URL. We’ll leave the issue of
ports there for now, and revisit that in more detail in the second semester in COMP18112.
3.4.1
A slightly more interesting web page
Next you’re going to create a slightly more interesting web page that contains a paragraph
describing who you are, which programme you’re on (e.g. Computer Science, Software Engineering, etc.), and which contains a picture of yourself as well as the image you created in the
previous session using Inkscape.
Use cd to change to your home directory, and then curl to fetch a gzipped tar of the example
Mr Noodle web page that we’ve created for you from:
http://studentnet.cs.manchester.ac.uk/ugt/COMP10120/files/mrnoodle.tar.gz
In your home directory, use tar to ‘untar’ this bundle of files using the command:
tar xvzf mrnoodle.tar.gz
Notice that this time we’ve added an extra z switch to the tar command’s argument which
tells tar to both ‘unzip’ and then ‘untar’ the file in one go (if you remember when you downloaded the Quake bundle in the first Pi session, you did this in two stages, first using gunzip,
and then tar).
gunzip
You should end up with a htmlexample2 directory containing an index.html file and two
image files, one in .png and the other in .jpg format.
Use a text editor to change the content of index.html so that it says something about you.
Don’t worry about finely crafted words here—this is really just a way of creating some files
that we can get you to edit in various ways a little later on. A few sentences will do, and you
can always change it later. Replace the default images we’ve provided with something that’s
relevant to you. Perhaps a photograph of yourself, and whatever it was you drew in Inkscape
would work here (though note, you’ll have to reopen the picture in Inkscape and export it to
a bitmap format such as .jpg or .png to be able to include it in your webpage).
You’ve already learned several ways of getting files onto your Pi, but here’s a reminder:
• You could mail the photo to yourself, and use Mutt to save the attachment onto the Pi
(for help on how to do this see Mutt’s online FAQ at http://dev.mutt.org/trac/
wiki/MuttFaq)
70
Introductory Labs
Pi power
• If the picture is already on the web somewhere, you could use Chromium to find and
save it.
• Alternatively for images on the web, you could use curl to fetch it directly from a URL
to a file.
• You could use scp to copy it from some other machine directly to your Pi.
• Or if all else fails, you could use a USB device to copy it from one place to another.
If you need more guidance on how to write the web page itself there are plenty of tutorials on
the web (search for something like ‘basic HTML tutorial’).
To finish this section, start up the SimpleHTTPServer that we used earlier but this time in your
htmlexample2 directory, and use Chromium to check that your web page is displaying correctly.
3.5
Headless Pi
Don’t Panic!
The rest of this lab session exposes you a fair number of quite advanced concepts pretty
quickly, and we don’t expect all of them to sink in this first time round. Stay calm. Don’t
panic. Just follow our instructions and everything will be fine; if you get lost or things
aren’t going to plan, just ask a member of lab staff to help you get back on track, and we’ll
revisit these ideas in later labs where there will be more opportunities to put them into
practice and make sure everything makes sense.
The Pi can be used as a respectable desktop machine, but it really comes into its own as a
server or controller for other pieces of hardware. In this section we’ll use the Pi in what is
called ‘headless’ mode—that is without its own screen and keyboard—to create a proper web
server to host your pages.
In a terminal, type the command ifconfig, short for ‘interface configuration’, which will give
you details about the network configuration on the Pi. This will return something along the
lines of
eth0
Link encap:Ethernet HWaddr b8:27:eb:f9:fa:ba
inet addr:10.2.232.41 Bcast:10.2.239.255 Mask:255.255.248.0
inet6 addr: fe80::881a:a651:7e67:9d44/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7210 errors:0 dropped:29 overruns:0 frame:0
TX packets:6784 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6605107 (6.2 MiB) TX bytes:6987416 (6.6 MiB)
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:356 errors:0 dropped:0 overruns:0 frame:0
TX packets:356 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
71
Introductory Labs
RX bytes:171392 (167.3 KiB)
wlan0
Pi power
TX bytes:171392 (167.3 KiB)
Link encap:Ethernet HWaddr b8:27:eb:ac:af:ef
inet6 addr: fe80::e8ae:1eef:86de:f574/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
This tells you that the Pi has two network devices currently active: one called ‘eth0’, which
represents the physical ethernet socket into which you plugged the blue network cable, and
which allows the Pi to communicate with other computers on the network (and in this case,
on the internet); a second one called ‘lo’ which is a ‘virtual connection’ or local loopback
connection that allows the Pi to route network traffic back to itself (this is how the ‘localhost’
trick you used earlier to look at web pages on the Pi worked). You can learn a lot more about
network configuration in the second year Computer Networks course (COMP28411); and a
third network device called ‘wlan0’, which is for wifi.
The thing we’re interested in right now is the IP Address that’s been allocated to your Pi. Look
for the line in the eth0 block of text that says inet addr: and note down the number that
follows this in your logbook (in the case of our example that is 10.2.232.41 but in your case
it will probably be something else). Don’t worry too much about what this number means or
where it came from for now—we’ll return to this in COMP18112 in the second semester. For
now, just treat this as being a unique number that identifies your Pi on the Computer Science
network.
In a moment, we are going to log in to the Pi from the PC, using ssh, but before we can do
that, we need to enable the Pi’s built-in ssh server, so that it can respond to ssh requests. This
is disabled by default, for security.
Bring up the Pi configuration screen again by typing
sudo raspi-config
Scroll down to Interfacing Options and tab to <Select>. On the next page that appears,
select the SSH line and <Select> that. At the prompt on the next screen ‘Would you like the
SSH server to be enabled?’ tab to and select <Yes>. If all is well a confirmation screen appears,
saying ‘The SSH server is enabled’. Select <Ok>, then quit the config tool. You’re now ready to
move to the next part of the lab.
Quit the graphical environment, and log out of your Pi by typing logout at the console’s command prompt (or you can press <ctrl>d to achieve the same effect). Leave the network logout
connection and power supply plugged in, but disconnect the mouse/keyboard lead, and reconnect them to the desktop PC. Switch the monitor over to display the desktop PC’s screen,
and log in to that with your University credentials.
Once you’re in the graphical window environment on the desktop PC, start up a terminal, and
use ssh to log into your Pi:
$ ssh [email protected][IPADDRESSOFPI]
replacing [IPADDRESSOFPI] with the IP Address you noted down a moment ago. Since this
is the first time you’re logging in from your CS account to your Pi, expect to see the ‘The
authenticity of host’ warning again; just say ‘yes’ to the prompt, and enter your Pi password.
72
Introductory Labs
Pi power
Change directory to the htmlexample1 directory you created for your web-page earlier, and
re-start the simple Python web server.
Next, start up Firefox on your desktop using the keyboard shortcut you created in the previous
lab session, and enter the URL:
http://[IPADDRESSOFPI]:8000
and you should see your web page appear, served off your Pi to the desktop machine just
like a real web server. Get the person next to you to see if they can see your web page from
their machine by using your Pi’s address; and return the favour by checking that theirs is also
working (it’s worth noting that the IP addresses of the Pis are only visible within the School of
Computer Science, so pages served off your Pi will not be visible on the wider Internet).
When you’ve finished this part, stop your Python webserver by typing <ctrl>c.
3.5.1
Setting up Apache, a proper web server
The simple Python-based web server that you’ve been running so far is doing the bare minimum necessary to allow HTML pages to be fetched by a browser. Although it was a handy
way of getting you going with web server technology, it’s a long way off being the kind of
fully-featured web server you would need to run a modern website. Fortunately, the Apache
HTTP Server—the software that is used to run over half the world’s websites—is Open Source
and runs quite happily on a Raspberry Pi. You wouldn’t want to be powering the next Amazon
or Facebook from a Pi, but to illustrate the principles, it’ll do the job nicely.
Before we install Apache on your Pi, there’s a bit of housekeeping to do that will conveniently
expose you to a few more Unix concepts that we’ve rather skated over so far.
3.5.2
Permissions, users and groups
Right at the beginning of these sessions you logged in to the Pi as a particular user called ‘pi’,
and on the desktop machines you’ve been logging in using your University username and
password. It’s fairly obvious what the general principles are here—logging in with a username
and password is a way of protecting ‘your stuff’ from being seen or messed around with by
other users. Roughly speaking this means two things: first, and most obviously, files created by
you should be in some sense ‘owned’ by you so that you can control who can see/modify them;
second, and perhaps less obviously, processes that you start—whether from the command line
or the graphical environment—are also ‘yours’ and have certain privileges/restrictions that
are associated with your user.
For this to work, it means that both the Unix file system and its way of dealing with processes
need to be aware of the notion of a user. Back in the terminal that’s connected by ssh to your
Pi, use cd to change to your home directory and type ls -l to list the files there in what’s
called ‘long format’ (the -l switch means ‘give me extra information about each file’). You’ll
see something like Figure 3.4 (but without the coloured background, which we’ve added to
help distinguish the different columns in the figure).
Working from right to left in Figure 3.4, column 7 contains the filename, column 6 gives
the date that the file was last modified (the exact format of the date will vary so as to always
be ‘useful’; older files will have a year instead of an exact time, for example) and column 5
shows the size of the file in bytes. Columns 4 and 3 give the group and user to which the
file belongs; we’ll come back to this in a moment. Column 2 shows the number of links
73
Introductory Labs
Pi power
total 76204
-rw-r--r-- 1
drwxr-xr-x 2
drwxr-xr-x 2
drwx------ 2
-rw-r--r-- 1
drwxr-xr-x 2
drwxrwxr-x 2
drwxr-xr-x 8
1
2
pi
pi
pi
pi
pi
pi
pi
pi
pi
pi
pi
pi
pi
pi
pi
pi
138240
4096
4096
4096
1726
4096
4096
4096
3
4
5
May
May
Oct
May
May
Aug
Jul
May
13
14
28
11
11
7
20
13
16:47
14:28
2012
10:50
12:06
13:23
2012
17:26
Advent.z5
build
Desktop
Mail
muttrc
mysite
python_games
quake3
6
7
Figure 3.4
An example of the ‘long format’ output from ls.
associated with the file (ignore this for now), and finally column 1 gives a summary of the
file’s permissions, which we’ll look at again shortly.
In our example, the file’s user (Column 3 ) is not surprisingly ‘pi’, which is the username
under which you logged in. Run:
$ ls -l /
(i.e. ‘long format list of the root directory), and you’ll see that the files at the top of the filesystem are owned by a user called root.
As well as being owned by a particular user, each file is associated with a group (shown in
column 4 , which in this case is a group called ‘pi’ too; although both the user and the group
are called pi here, they are different things). Every user is a member of one or more groups.
The idea of a Unix group is quite straightforward: it’s a mechanism to allow collections of
users to share resources with one another in a controlled way, while stopping other unwanted
users from being able to access those resources. For example, you might want to say “Only I
as this file’s creator am allowed to modify or delete this file, but other members of my Tutorial
Group can read the file’s content, and the file is inaccessible to everybody else”. In Unix each
file can have three different types of access permission: read, write and execute (run). These
permissions can be set for three different categories of user: user (‘owner’), group (a specific
set of users) and ‘other’ (which means ‘everyone else’).
The file permissions shown in column 1 of Figure 3.4 consist of 10 ‘slots’ as shown in more
detail in Figure 3.5. The first slot indicates the type of the file, and appears as a - for a regular
file or a d for a directory. The next three slots represent the user’s permissions and can consist
of any combination of r for ‘readable’, w for writable and x for executable. The next three slots
show the read/write/execute permissions for members of the file’s group, and the last three
slots show the same set of available permissions for other (i.e. anyone else with access to the
system). Execute permissions when applied to a directory mean that particular set of users can
access the directory’s contents.
We’ll come back to file permissions in more detail shortly. In the meantime, let’s look at the
ownership model for processes. Type:
$ ps waux
to list any processes that are currently running (you’ll probably need to widen the terminal
window to see the output properly). The ps command is unusual in that if used with no
74
ps
Introductory Labs
Pi power
user
group
{
{
{
other
{
drwxr-xr-x
type
Figure 3.5
Unix file permissions as shown with ls -l. In this example shows the permissions for a
directory that can be read from, written to and listed by its user (owner), but only read and
accesed by group members or anyone else.
arguments, its output is largely uninformative. It’s also unusual in that explaining what even
the most basic arguments do and how they interact (i.e. the waux options in this case), is quite
complex—so for now just treat this as a special recipe that does something useful. Note that
there’s no hyphen in front of the options in this case.
Look at the rightmost column of the output (which has the heading ‘COMMAND’) and you
should see a few familiar process names such as bash, startx, and the ps process itself in
amongst many commands that will be unfamiliar to you at the moment. The leftmost column
tells you who owns the processes, and you’ll see that some of them are owned by you (or,
rather by the user ‘pi’), and others are owned by the root user. Most of the processes that
you’re seeing have been started as part of the window manager system, or are in one way or
another associated with X Windows; the rest are ‘housekeeping’ processes the details of which
we don’t care about for now.
If you think back to what you learned about the hierarchical relationship between processes
in the first Pi lab, it should be starting to become clear how the ‘family tree’ of processes when
combined with the notion of users and resource ownership knit together nicely to give a secure
multi-user system. When you first log in to a Unix machine, a single process is started on your
user’s behalf (in most cases this is a command shell). From that shell you can start other
processes, which could be individual commands like tar or ls, or could be a whole window
manager system such as GNOME or LXDE; in either case though, these inherit the properties
of the parent shell in terms of being owned by the same user. Then, any processes that are
started by the window manager also inherit the same user properties, and so forth.
3.5.3
Back to that webserver
Anyway, let’s get back to setting up the Apache web server. When you ran the Python web
server, that was a process owned by you, and because we didn’t do anything special to protect it, if you closed the shell/terminal that was used to start it, it too would die. Generally
speaking, you’d want a web server to continue running whether anyone was logged into the
machine or not, so this isn’t ideal. The other issue with starting a web server in this way is that
because the process is owned by you, it has access to all your files—so if a malicious hacker
was able to take control of the web server process, he or she would be able to read or even
delete your work, which clearly isn’t a good thing.
So to set up a web server properly we need to:
• make sure that it can continue to function after you’ve logged out, and
• somehow make sure that it can only access a specific set of resources that represent the
website, and not run riot around your filestore doing bad things.
75
Introductory Labs
Pi power
Let’s first tackle the issue of a shared directory; this is quite easy to set up using Unix’s group
mechanism.
By default, the Apache package that we’re going to install shortly is set up to serve web pages
from a directory called /var/www and although you can change it in Apache’s configuration
files to be elsewhere, that’s as good a place as any for what we need.
Let’s go ahead and install Apache using the command:
$ sudo apt-get install apache2
It’s a reasonably large package so may take a little while to install; just be patient. If a message
comes up like ‘Do you wish to continue?’, type y. Once the installation has completed, take a
look in /var using ls -l and you should see a directory in there called www which is owned
by root.
Before we start serving any web pages, there are a few security issues that we need to take
into account. In its simplest form, where you’re just serving static web pages (i.e. HTML files),
Apache is secure enough, but as soon as you start creating web sites where users can add and
modify content on your server, you potentially open yourself up to malicious damage, so it’s
best to take some initial precautions.
Take a look at the permissions for /var/www, which was created when you installed the Apache
package, and you will see that they are set to drwxr-xr-x which means ‘this is a directory that
the owner can read, write and access the contents of, and which both group and other users
can only read and access’. Notice too that there’s a directory in /var/www, called html, and a
single file in that directory called index.html, which is an ‘it works!’ declaration that you can
use to test that Apache is doing the right thing (and which we’ll do shortly). The important
thing here is that anybody or any process that is not running as the root user has only got read
and not write access to the contents of the /var/www directory structure—and this is exactly
what we want. They can look, but not touch, and so can’t break anything.
But how do we get content into the /var/www directory so that it can be served by Apache?
We could simply use sudo to give ourselves root privilege every time we need to modify a file,
but that’s a rather clumsy solution: we may not want other users on our machine to have root
access at all, and in any case you really do want to keep sudo commands to a minimum so that
you don’t accidentally do something bad to your system. So let’s create a new group that will
represent users on the Pi that are allowed to put content into that directory. Use the command
addgroup to create a new group called www-contrib (for ‘web contributors’). The syntax is
straightforward:
addgroup
$ sudo addgroup www-contrib
And you should see that a new group has been created with a Group Identifier (GID) probably
set to 1001.
Change the group ownership of /var/www to be www-contrib using the command
$ sudo chgrp -R www-contrib /var/www
and check that this has changed using ls -l. Note that we’re using the -R option to chgrp,
which means ‘apply this change not only to /var/www itself, but to all files and directories
contained within it’ (R here stands for recursive ). Next we need to add the pi user to that
group. Type
W
76
chgrp
Introductory Labs
Pi power
$ groups
to see what groups your user is already a member of (you’ll see things like pi, adm, dialout,
cdrom, sudo and several others). Use the command:
$ sudo usermod -a -G www-contrib pi
to add the pi user to the www-contrib group. The usermod command can be used to modify
lots of things about a user; here we are using with the combination of -a and -G to mean usermod
‘append this group to the user’s list of groups’. You’ll need to log out and back in again to
see this change take effect, so do that now: type logout. This will log you out of the Pi and
also close the ssh connection, so start that connection again with the ssh command as you did
before. Back in the Pi, run the groups command to confirm that pi is now indeed a member
of group www-contrib as well as the other original groups.
We now need to make the /var/www folder writable by members of our new group, so do that
using the command:
$ sudo chmod -R g+w /var/www
which reads as ‘modify the permissions of the directory /var/www and any files/directories in
it to add write access for members of its group’.
Now if all has gone to plan, the user pi should be able to read and write to the directory
/var/www. Try this out by editing the content of the index.html file that’s in the html directory (and which was created when you installed Apache) to say something different from the
default text.
We’re finally ready to start Apache. Use the following command:
$ sudo service apache2 start
to initialise the server (you can use a similar command with stop to shut it down again), and
then use ps waux to confirm that you can see several processes with apache in the name now
running. Note that although you started the server with sudo which runs things as root, that
the owner of the Apache processes is www-data. The service apache2 start command has
restricted Apache to running as a regular, non-root user, and you should by now be able to
work out why having a web server running as root would be a Bad Thing from a security
point of view.
On the desktop machine use a web browser to see what content the Pi is now serving. The
URL will be:
http://[IPADDRESSOFPI]
and since we’re now using a standard web server on a standard port (port 80), there’s no need
to add the :8000 port number as we did in Section 3.5.
You should see the ‘It works!’ page appear, with whatever modification you made to it a
moment ago.
Nearly finished. Copy the content from your htmlexample2 directory so that its served via
Apache, and check using a web browser that the ‘It works!’ page has been replaced by your
own masterpiece.
77
Introductory Labs
3.6
Pi power
Shutting down gracefully
That’s all the exercises done for this lab session; but before you finish there’s one last important
thing to do. Make sure you use the halt command to shut your Pi down cleanly, otherwise
you risk losing some of your work by corrupting its file system. You can do this over a ssh
connection quite safely, so you don’t need to reconnect the keyboard/mouse/monitor to the
Pi, just type sudo halt in the secure shell that’s running on the Pi. Of course, you shouldn’t
be surprised when secure shell gets disconnected as the Pi begins to shut itself down.
3.7
Finishing up
Don’t worry if not everything you’ve done in this session has sunk in yet—you’ve encountered
a lot of new concepts in this session, and we’ll be revisiting everything in one form or another
in future labs. This is the last lab that uses your Pi for a while now, and in the next session
we’ll be introducing you to the virtual learning environment that will be used for several of
the course units this year, and giving you an opportunity to practise some of the skills and
techniques that we’ve covered already. But this isn’t the last you’ll see of the Pi—you’ll be
using it as part of your group project in COMP10120, so please don’t lose it. In the meantime,
remember that even if you do something wrong on the Pi, it’s very easy to restore it back to
a clean state, and we encourage you to explore Unix and have fun with this fantastic bit of
hardware.
78
Intro Lab Session 4
Introduction to Blackboard and
command line skills
Contents
4.1
4.2
4.3
Getting started with Blackboard . . . . . . . . . . . . . . .
4.1.1 The COMP10120 course unit site . . . . . . . . . . .
4.1.2 Lab deliverables . . . . . . . . . . . . . . . . . . . .
4.1.3 Using discussion boards . . . . . . . . . . . . . . . .
4.1.4 Using wikis . . . . . . . . . . . . . . . . . . . . . . .
4.1.5 Writing your reflective journal . . . . . . . . . . . .
Reinforcing your command line skills . . . . . . . . . . .
4.2.1 Creating a directory structure . . . . . . . . . . . . .
4.2.2 Copying, moving, and removing files . . . . . . . .
4.2.3 Practice makes perfect . . . . . . . . . . . . . . . . .
4.2.4 Wild cards . . . . . . . . . . . . . . . . . . . . . . . .
4.2.5 Quotas . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6 Putting commands together . . . . . . . . . . . . . .
4.2.7 Making your own commands . . . . . . . . . . . . .
4.2.8 Doing several things at a time: background running
4.2.9 Printing text files: lpr . . . . . . . . . . . . . . . . . .
4.2.10 Time for a checkup . . . . . . . . . . . . . . . . . . .
4.2.11 Exercises . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.12 The end of the beginning . . . . . . . . . . . . . . .
Acknowledgements . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
80
80
81
81
81
82
82
83
85
86
88
89
89
91
93
93
94
95
96
96
These notes are available online at
syllabus.cs.manchester.ac.uk/ugt/COMP10120/labscripts/intro4.pdf
We suggest you use the online version so that you can follow web links.
This is the last of the introductory labs, and is designed to introduce you to the main virtual
learning environment used across the University, Blackboard, and to give you a chance to
practise the command line skills that you’ve learned already, plus a few more, so that you’re
ready for when the regular scheduled labs start. As always, don’t rush through the material,
and if you get at all stuck please ask a member of lab staff for help. All the work today should
be done using Linux on a desktop PC.
September 8, 2017
79
Introductory Labs
4.1
Blackboard Intro and command line skills
Getting started with Blackboard
In the first half of this session you’ll be introduced to the Blackboard Virtual Learning Environment (VLE). Blackboard is designed to support teaching by providing an online place to
upload resources for course units. It also provides useful tools such as discussion boards and
quizzes. All course units have a Blackboard course unit site, which provide a first place to look
for unit resources; we will be looking in particular at ways in which it is used in the First Year
Team Project, COMP10120.
Blackboard has several features which make it well suited to supporting COMP10120. These
include:
• It’s one useful way of communicating with your tutor and members of your tutor group.
• It allows us to give each group a wiki which you’ll use to collaboratively document your
group’s meetings and the decisions you make as part of your project work.
• It provides a structure to help organise activities you should be doing on a week-by-week
basis.
As a brief introduction to get you started using Blackboard, please take a look at
http://studentnet.cs.manchester.ac.uk/ugt/COMP10120/files/BlackboardIntro.pdf
4.1.1
The COMP10120 course unit site
Now login to Blackboard and navigate to the COMP10120 site and start to look at how the site
is structured and what tools have been provided. Here are some things you should note about
the structure of the site:
• One of the most important items on the main page is the coloured table of all your activities for this course-unit. The different phases are colour-coded to help you spot the one
you want. The row for each week contains links to information about what you should
be doing in that week and tools/resources applicable to the week. (Don’t forget to read
the phase overview first.) The Other column includes resources for your personal use, that
you are expected to complete during this academic year. In particular you should note
the reflective journals for each week of the first semester. You are expected to reflect on the
questions detailed inside the journal each week.
• General instructions for the course unit are located in the General Project information area
on the front page. Take a look at each of the links in this area.
• Back on the course unit site, in the left hand panel you will find Course Tools. This link
leads you to a number of tools, including the Course Discussion Board. There is also a
direct link to this board on the front page. You should subscribe to this discussion board
now.
• Also on the left hand side, under My Groups on the left hand side, you should find a
link labelled with your tutorial group name. This is where the resources for your group
can be found, including a discussion board which can be used to communicate with
members of your group and a wiki in which you can document your work. Again you
should subscribe to this discussion board.
80
Introductory Labs
4.1.2
Blackboard Intro and command line skills
Lab deliverables
By the end of this section of the lab session, ensure you have completed the following tasks.
• Posted a welcoming message to your tutor group (see Using Discussion Boards below).
• Create your set of practice wiki pages (see Using wikis below).
4.1.3
Using discussion boards
Most of you will have used discussion boards, or forums, in some way or another, whether on
your favourite social networking site or on some other website.
Visit your Group Discussion Board on the COMP10120 site and click on Create Thread to begin
a new discussion thread. Write a short posting to introduce you to your other group members
and your tutor. Let them know where you are from, tell them a little bit about yourself.
4.1.4
Using wikis
You have almost certainly come across wikis before, and will no doubt have looked things up
in Wikipedia , the world’s biggest wiki, many times. Unlike many other online collaboration
systems which constrain users in various ways by pre-determining the type of content that can
be created (for example sites like Instagram and Flickr are designed for sharing photographs,
where as Soundcloud is for sharing audio), and also categorising users as having different
types of access (e.g. administrators, moderators, regular users and so forth), the technology
behind wikis typically takes a very liberal approach to both users and content. They generally
allow any user to make any kind of change to any kind of content, and rely on social conventions established by the community to keep things sane. In particular, every edit, deletion and
addition to the wiki is stored, providing a complete history of wiki changes. Old versions of
pages can be retrieved and compared to new versions of pages.
W
As well as creating sites like Wikipedia, wikis are frequently used by software development
teams to document their project. The ability to look back to previous versions of documents
and for multiple authors to collaborate on producing the documentation without having to
worry too much about ‘process’ is particularly useful in such environments.
During COMP10120 you’ll be required to document many aspects of your work using a group
wiki provided by Blackboard. You can find this wiki under My Groups on the left hand side.
For the purposes of this mini-tutorial you are asked to create some interlinked wiki pages
about yourself. It is important that you follow this through to the end as it will ensure you
know how to do all the basic tasks needed to help build your own group wiki during the
project.
Start by creating a page in your group wiki by clicking on Create Wiki Page; it probably makes
sense to include your name or initials in its title to avoid confusion with pages created by
other group members. You will be presented with the Blackboard editor which won’t have
any content yet.
Select the Submit button. You should now see the first page of your wiki with the content you
just added. You can add more content by selecting the Edit Wiki Content tab.
Create a short bullet list containing the items My hobbies, My music and My files. Save the page
again and check the results, then select the Edit tab again. Now turn the three items into wiki
links. To do this, use the Create Wiki Page to make suitably named new pages (again including
81
Introductory Labs
Blackboard Intro and command line skills
something to make them personal to you, such as your name or initials). Then, back on the
page with the bullet list, select each item of the list in turn and use strange looking icon with
several pieces of paper to link the text to each of your new pages.
This is the basic process by which you build up a wiki into a series of linked pages.
You can find lots of information about Blackboard wikis at https://en-us.help.blackboard.
com/Learn/Student/Interact/Wikis
Now go back and select the question mark link for the My music link and add some content to
this page too. You could write about music you love (or music you hate!).
In the last part of this mini-tutorial, you will need to add a small picture to your wiki and a
small file. First we need some files to play with. If you have a small picture that you took
yourself, great, you own the copyright on it, otherwise look for a copyright free image on the
web.
Finally, browse through the remaining documentation on Wikis at the link given above so that
you have an overview of what other information is there and can refer back to it in the future
if needed. If you have any questions about how to use the wiki tool, post a message to the
Course Discussion Board.
4.1.5
Writing your reflective journal
One of the aims of this course unit is to encourage you to develop the habit of thinking about
the way you are learning and working, and trying to identify ways in which these could be
improved. The process of reflection is key to this, but is not something that comes naturally to
many of us. In most weeks, the course unit site has a link to an instance of the Journal activity.
Any entries you put into your journal will not be visible to other students. They will be visible
to course unit tutors and course unit organisers, but they will respect your privacy.
At some time towards the end of this week, start your journal entry for the current week. Some
brief notes about the process of Reflection can be found at https://goo.gl/gC3LYX.
That’s all we want to say about Blackboard. The second part of this lab is about using the
command line in Linux.
4.2
Reinforcing your command line skills
This section is designed to help you practise your command line skills in preparation for next
week’s start of regular lab activities. You’ve already used most of these commands in previous
labs, but please don’t rush through this section since we’ll be explaining their behaviour in a
bit more detail, and introducing you to some of the extra options they provide, as well as some
of the pitfalls that lie in wait for the over-zealous command line user.
You’ve probably figured this out already, but it’s worth making explicit here: for Unix commands, it’s usually the case that no news is good news. So when you run a program from
the shell, if you get no response other than your command-prompt back, that almost always
means that the command has done what you asked it to (whether you asked it to do what you
wanted it to do is, of course, an entirely different matter!). Generally speaking, for most simple
Unix commands, you can assume that the absence of an error message means that something
has worked. And of course, if you get an error or warning message back from a command, it
is crucially important that you read it, understand it, and act on it, rather than just ploughing
82
Introductory Labs
Blackboard Intro and command line skills
on regardless. If you ignore errors and warnings, bad things happen. This is true in the Unix
command world, and probably isn’t a bad philosophy for life in general either.
Anyway, back to the exercise and some practice of manipulating files and directories. In previous labs you’ve already encountered three directories of particular interest:
• The root directory (/) is the top level of the file system.
• Your current working directory which is the one you are ‘in’ at the moment (and is
shown by the output from pwd). This can also be referenced using a single dot (.), as you
did when starting up Quake Arena using ./ioquake3.arm in your first Pi lab.
• Your home directory (~) which is the top level of your own filestore and where cd
(change directory) with no arguments will take you. The value of this is also available
as $HOME, so the following all have the same effect:
$
cd
or
$
cd ~
or
$
cd $HOME
And no matter what is your current working directory, you can list the files in your home
directory with either of these commands.
$
ls ~
or
$
ls $HOME
You should recall the difference between an absolute path (one that starts with a /) and a
relative path (one that does not start with / but is instead ‘found’ relatively by starting from
the current working directory). You’ve met the ‘double dot’ notation (..) to mean ‘go up one
level’, as in ls .. or perhaps more often cd .., or even cd ../x/y and so forth.
Speaking of ls, you will from time to time need to use its -a switch argument to ask it to show
‘hidden’ files beginning with a dot, and/or -l (a letter l, not a digit 1) to make it show details
about the files it lists.
4.2.1
Creating a directory structure
Use the mkdir (make directory) command to create some directories. Type:
$
$
cd
mkdir INTRO
83
Introductory Labs
Blackboard Intro and command line skills
and check that this directory has indeed appeared using ls.
It’s important that directories we ask you to make for your work have exactly the names we
specify: Unix will let you use any names you like, but so that lab staff know where to look
for work when you get marked, and so that the system you’ll be using to submit your work
knows what you’re submitting, it’s very important that you follow these conventions for your
lab work. Any files and directories you create for your own purposes outside of lab work can
of course be named and organised however you like.
If you made a mistake, e.g. intro instead of INTRO, you can remove the directory while it is
still empty with the rmdir command: e.g.
$
rmdir
rmdir intro
And then try to make it correctly.
Now go into your INTRO directory and let’s make some directories for four imaginary INTRO
exercises.
$
mkdir ex1 ex2 ex3 ex4
Now return to your home directory.
Your directory structure should now look something like this:
$HOME
INTRO
ex1
ex2
ex3
ex4
The easiest way to check this is to use ls from your home directory with the -R flag. This
shows the whole tree below your current working directory (as with other commands we’ve
encountered before such as chmod, here the -R is short for recursively —if you’ve not looked
up what this means yet, now is a good time to do that).
W
$ ls -R
Next make a directory in your home directory for the COMP16121 course unit with subdirectories for each of the 10 exercises associated with that course (these aren’t imaginary exercises, you’ll be starting on them next week). You must use the same convention as above:
capital COMP16121 and lower case ex1 and so on.
You must get your directory structure right before continuing—be extremely careful that you
get this right.
84
chmod
Introductory Labs
Blackboard Intro and command line skills
Now try the following sequence of cds, checking where you are by running pwd after each
one, and make sure you understand what is going on: if you’re at all unsure about what has
happened, please grab a member of lab staff to get an explanation—it really will save you a lot
of hassle in the long run.
cd
cd
cd
cd
cd
cd
cd
4.2.2
INTRO/ex1
..
ex2
../ex1
../../INTRO/ex2
../..
Copying, moving, and removing files
This subsection re-introduces three commands used for copying, moving and removing files.
We’ll first describe each command and then you’ll get an opportunity to practise using them.
Copying files: cp
The cp (copy) command has two forms.
The first general form is
$
cp [FILENAME] [FILENAME]
For example
$
cp file1 file2
makes a copy of the file file1 and calls it file2. If a file called file2 already exists, the existing
file2 will be overwritten with a copy of file1 and lost without warning. Using the -i option to
cp will ask you if this is about to occur.
The second form is slightly different:
$
cp [FILENAME(S)] [DIRECTORYNAME]
For example
$
cp file1 file2 file3 dirname
This copies the files file1, file2 and file3 into the directory dirname, again overwriting
any files already there with the same names.
Removing/deleting files: rm
The command rm (remove) is used to delete files.
$
rm
rm [FILENAME(S)]
85
Introductory Labs
Blackboard Intro and command line skills
throws away the specified files. Always take great care when using rm: unlike putting things
in the ‘trash’ or ‘recycle bin’ in a desktop environment, the effects of rm are not reversible, and
you don’t get any warning before files are deleted forever. Like cp, rm has a -i option which
asks you if you really mean it. This option can be particularly useful if you are using wildcards
in you command line arguments.
Moving / renaming files: mv
The mv (move) command is similar to cp, but it just moves the files rather than makes copies.
Again we have the two forms
$
mv [FILENAME] [FILENAME]
and
$
mv [FILENAME(S)] [DIRECTORYNAME]
The effect is similar to copying followed by removing the sources of the copy, except it is more
efficient than that (most of the time). For example
$
mv file1 file2
is like doing
$
$
cp file1 file2
rm file1
and
$
mv file1 file2 file3 dirname
is like doing
$
$
cp file1 file2 file3 dirname
rm file1 file2 file3
Using mv will preserve the timestamps on files, whereas the combination of cp and rm will not,
since new files are being created.
4.2.3
Practice makes perfect
Now for some practice. Go to your home directory by typing:
$
cd
and copy the file called fortunes in the /usr/share/games/fortune directory to your current working directory, by typing
$
cp /usr/share/games/fortune/fortunes .
86
Introductory Labs
Blackboard Intro and command line skills
Breakout 4.1: Taking out the trash
You now know enough about the behaviour of the filesystem to know what’s
actually going on when you put files in the ‘recycle bin’ or ‘trash can’ in a
desktop environment such as you get with OS X, Windows or Gnome. When
you ‘move to trash’ in these environments, you’re not deleting the file but instead using an equivalent of the mv command to move the file from its current location into
a special directory that represents the trash can. When you tell the graphical environment
to ‘empty trash’, you’re actually invoking something equivalent to rm, which actually does
delete the file from the filesystem.
Breakout 4.2: fortune
At the moment we’re just going to be using the fortunes file as something to
copy and move around, so its contents are not important, but it’s one of the
source files used by the Unix fortune command, which we will be playing
with later.
W
fortune is a simple program that displays a random message from a database of (supposedly) humorous quotations, such as those that can be found in the US in fortune cookies
(hence the name). It also contains jokes (of a sort!) and bits of poetry.
W
W
Note that the dot (meaning, of course, your current directory) is essential. If you now do an
ls, you should see that the file called fortunes has appeared in your directory:
$
ls
If no file called fortunes has appeared, the following will probably provide an explanation.
If it did appear, read this anyway, just to check that you understand what you did right.
The cp command needs at least two arguments. In this case, the file you are copying is
/usr/share/games/fortunes, and the directory you are copying it to is ‘.’ (that is, your
current working directory; remember every directory has a reference to itself within it, called
‘.’) If you missed out the dot, or mis-spelt /usr/share/games/fortunes, or missed out one
of the spaces, it won’t have worked. In particular, you may well have got an error message
like:
cp: missing destination file
Try ‘cp --help' for more information.
or
cp: /usr/share/games/fortunes/frotunes: No such file or directory
If you get the first message, it means you used the command with the wrong number of arguments, and nothing will have happened. The other is an example of what you might see if
you mistype the first argument. If you do get an error message you need to give the command
again, correctly, to copy the fortunes file across.
87
Introductory Labs
Blackboard Intro and command line skills
You should now have a copy of the file in your home directory. You’ll have to get into the
habit of not having all your files in your home directory, otherwise you will quickly have an
enormous list of stuff that will take you ages to find anything in. The use of subdirectories
provides a solution to this problem, which is why you created some earlier. Moving this file to
the ‘correct’ place gives you a chance to practise the mv command.
Move the file fortunes to your INTRO/ex4 directory.
Now go to your INTRO/ex4 directory and check that the file has appeared there.
To make sure you understand cp, mv, and rm, go through the following sequence (in your
INTRO/ex4 directory), checking the result by looking at the output from ls at each stage:
$
$
$
$
$
$
$
$
$
$
$
$
cp
ls
cp
ls
mv
ls
cp
ls
rm
ls
rm
ls
fortunes fortune1
fortunes fortune2
fortune1 fortune3
fortune3 fortune4
fortune2
fortune1
You’ll notice that rm fortune1 behaves differently to rm fortune2; if you can’t figure out
why, ask a member of lab staff for help.
4.2.4
Wild cards
An asterisk (commonly referred to as star) in a filename is a wild card which matches any
sequence of zero or more characters, so for instance, if you were to type (don’t actually do it!)
$
rm *fred*
then all files in the current directory whose names contain the string ‘fred’ would be removed.
Try the effect of
$
ls fortune*
and
$
ls *tun*
Now try
$
echo *tun*
Our previous use of * has always been in conjunction with ls which might have led you to
think that the wild card was being expanded by ls. In fact the expansion is done by the
shell, bash, which means that the effect is true for anything you type on the command line.
88
Introductory Labs
Blackboard Intro and command line skills
Wildcards are a very powerful and useful feature of the command line, and as with anything
powerful and useful can be used or mis-used, so it’s important that you know what you’re
doing with them.
One place where you must take care with wild cards is the dotfiles—these are files whose
names begin with a dot (.), because the asterisk will not match a . at the start of a file name.
To see what this means try the following
$
$
cd
ls *bash*
and
$
ls .*bash*
and see the different output.
4.2.5
Quotas
The command
$
quota
shows you what your file store quota is, and how much of it you are actually using. This is
only of academic interest now, but may become very important later in the year! You may find
that you are unable to save files if you use more than your quota of file store. It is important
that, if this happens, you do something about it immediately.
4.2.6
Putting commands together
Redirection
Before you forget that you’re in your home directory, change back to your INTRO/ex4 directory.
One of the simplest (and most useful) of Unix commands is cat. This command has many
uses, one of which is to concatenate a list of files given as arguments and display their contents
on the screen. For example:
$
cat file1 file2 file3
would display the contents of the three files file1, file2 and file3. The output from cat
goes to what is known as the standard output (in this case the screen).
If you type:
$
cat
nothing will happen because you haven’t given a file to cat. When run like this, it takes its data
from the standard input—which in this case is the keyboard—and copies it to the standard
output. Anything that you now type will be taken as input by cat, and will be output when
each line of the input is complete. In Unix, end of input is signalled by <ctrl>d. (Recall that
typing <ctrl>d in your login shell will log you out—you have told the shell to expect no
more input). So, after typing cat above, if you type:
89
cat
Introductory Labs
Blackboard Intro and command line skills
The cat
sat
on the
mat
and then press <ctrl>d you will see the input replicated on the output (interleaved line by
line with the input). The first copy is the ‘echo’ of what you typed as you typed it, the second
copy is output from cat. This may not seem very useful, and you wouldn’t actually use it just
like that, but it illustrates the point that cat takes its input and copies it to its output. Using
this basic idea we can do various things to change where the input comes from and where the
output goes.
$
cat > fred1
will cause the standard output to be directed to the file fred1 in the working directory (the
input still comes from the keyboard and will need a <ctrl>d to terminate it. Try creating a file
fred1 using this technique, and then check its contents.
$
cat < fred1
will take the standard input from the file fred1 in the working directory and make it appear
on the screen. This has exactly the same effect as
$
cat fred1
You can, of course, use < and > together, as in
$
cat < fred1 > fred2
which will copy the contents of the first file to the second. Try this and check the results.
We can, of course, do this type of redirection with other commands. For example, if we want
to save the result of listing a directory’s contents into a file we just type something like:
$
ls -l > fred1
(this overwrites the previous contents of fred1 without warning, so be careful of this kind of
use).
In the previous Intro lab session we met the idea of a pipe, using the | symbol to connect the
standard output of one command to be piped to the standard input of a second.
We can construct another (admittedly rather artificial) pipeline example using just cat:
$
cat < fred1 | cat > fred2
The first cat takes its input from the file fred1 and sends its output into the pipe. The second
cat takes its input from the pipe (i.e. the output from the first cat) and sends its output to the
file fred2. (How many other ways can you think of to do this?) This isn’t a very sensible thing
to do, but it does illustrate the principle of piping, and more realistic examples will appear in
the exercises.
Standard output sent to the screen may come so fast that it disappears off the top before you
have had a chance to read it. There is a simple way around this problem by piping the output
into the command less which arranges to stop after each pageful (or screenful, or window-ful)
of output. For example,
90
Introductory Labs
Blackboard Intro and command line skills
$ ls -la | less
would be a wise precaution if the current working directory held more than a screenful of
entries. When less has shown you the first screenful, press the space bar to see the next
screenful, or return to see just the next line. Use q as usual to quit.
Now would be a good time to remove all those junk files like fred1 etc.
Before we leave the subject of pipes we meet two of the less obviously useful Unix commands,
fortune and cowsay. We met fortune briefly in Breakbox 4.2, try running it a few times now.
(Hope you didn’t type the command more than once. If you did, think how that could have fortune
been avoided.)
Now try running the command cowsay. Nothing happens, because the cow is waiting for you
to tell it what to say. Type anything you like and then <ctrl>d to denote the end of input. cowsay
The cow should then utter your words:
_____________
< Hello World >
------------\
^__^
\ (oo)\_______
(__)\
)\/\
||----w |
||
||
Now try putting fortune and cowsay together to get the cow to ‘speak’ the fortunes. Utterly
useless but it illustrates the use of pipes.
4.2.7
Making your own commands
Pretty much anything that you can type at the command line can also be stored in a file to
create a simple program called a shell script, so if you find yourself frequently connecting
together simple commands to perform a particular task, you might find it useful to create a
script for use in future, rather than retyping everything each time. If you recall back to Section
2.3.1 we made a simple command called mankyweather using an alias. Aliases are fine for
things that you can express in a single line of text, but clumsy for more complex combinations
of commands; a shell script instead allows you to use as many lines as you like.
Use an editor to create a shell script in the file ~/bin/wisecow. Make a directory in your home
directory called bin using the command:
$ mkdir ~/bin
and in that directory create a file called wisecow. You’re welcome to use whatever text editor you like for this, but you might find that for short edits like this you’re better off using
something like nano rather one of the more heavyweight graphical editors.
Put the following text into the file:
#!/bin/bash
fortune | cowsay
91
Introductory Labs
Blackboard Intro and command line skills
Breakout 4.3: Scripting versus Programming
You may be wondering what the difference is between a ‘script’ and a ‘program’, or between the idea of ‘scripting languages’ or ‘programming languages’. It’s quite difficult to pin down exact meanings for these, since their
use has shifted over time and different people use the terms to mean subtly
different things. Scripting languages and programming languages both allow people to
create sequences of instructions for a computer to execute. Generally speaking when people refer to scripts or scripting languages they are referring to mechanisms for automating
tasks rather than for performing complex computations. So if you wrote something that
once a month deleted any files that ended with .bak from your filestore, you would probably use a scripting language, and most likely think of it as a script. If you were to write
the next 3D blockbuster console game to outsell Grand Theft Auto V, you’d probably use a
programming language and think of it as a program. At the extreme ends of the spectrum,
the distinction is quite clear; in the middle it gets a bit muddy.
The first line tells the operating system to use the program /bin/bash when this script is run,
i.e. it will start bash with an argument telling it to get its commands from this file and execute
them pretty much as though they had been typed into bash in the usual way.
Now try to run your new program:
$
~/bin/wisecow
Oops, that won’t have worked! Before the operating system will believe us that this really
is a thing that we can run, we need to give the file execute permission. Use ls to see what
permissions the file has at the moment. To make it executable we use chmod as follows.
$
chmod +x ~/bin/wisecow
Now check its permissions again. If all is okay, you should be able to run this time with
$
~/bin/wisecow
and your wise cow should have spoken.
Now here is the really cool bit: in an earlier lab you met the idea of $PATH—the list of all places
where the operating system will search when you type a command without specifying its full
pathname. See the value of this now:
$
echo $PATH
Notice one of the directories listed is your very own ~/bin directory: this is where you can
put your own commands.
So, now type just
$ wisecow
and bask in the wisdom of your newly created cow guru.
92
Introductory Labs
4.2.8
Blackboard Intro and command line skills
Doing several things at a time: background running
The command xclock fires up a clock displaying the current time; try it now.
You will notice that there’s a problem with running clocks from a terminal window. If you xclock
type:
$ xclock
a clock does indeed appear. However, you then can’t type any more commands in the terminal
window, because it is waiting for the clock program to finish, and of course the clock program
is designed to run forever (or at least until you logout). In this situation you can, of course quit
the clock, using <ctrl>c in the terminal window. However, if you want to keep the clock
running and still get on with other things in the same terminal window you can just add an
ampersand (&) on the end of a command, so in this case,
$ xclock &
Adding the ampersand ensures that the program is run in the background, that is, separately
from the terminal window. This way you can have several clocks at once and continue typing
other commands carrying on from where you were.
Try running an xclock in the background now.
Work out from the manual page for xclock how to use its various options, and experiment
with producing a range of clocks. (You should ignore the section of the manual page entitled
X DEFAULTS – for now.)
One situation where the use of background processes is particularly useful is when you fire up
an editor, such as gedit. You can start the editor and still continue to do other things in the
same terminal window. Try this now
$ gedit &
You can also start gedit (and many other editors) with a filename argument to edit a particular
file; in fact this is probably the way you will normally use it.
Sometimes you might forget the & and want to put a process into the background while it
is already running. This is easy to do; first you suspend the process by typing <ctrl>z,
then type bg to put into the background. Try this now with a gedit window. You can bring
a background process back into the foreground by typing fg. If you have more than one
suspended or background job then you just add the background process count as an argument;
you can find which process has which count by using the shell command jobs.
4.2.9
Printing text files: lpr
The command lpr can be used to send files to a printer. In its simplest form, you simply run:
$
jobs
lpr file1 file2
to print the given files. The printing service we use is the University Pull printing service,
which allows you to collect your printing at any University pull printer. This is described in
more detail at
http://www.itservices.manchester.ac.uk/students/printing/
93
lpr
Introductory Labs
Blackboard Intro and command line skills
You could use lpr now to print out the fortunes file, but that file is quite big and we don’t
want to waste a lot of paper. So please don’t! However, it would be nice to practise using
lpr. So instead print out just the first 50 lines of it. Look at the man page for lpr and discover
what it does if no file names are given. Now look at the man page for the command head and
figure out how to make it output the first 50 lines of the file fortunes. Experiment with this to
make the 50 lines appear on your screen. Now send the 50 lines to the printer—without using
a temporary file. Go and collect your print output from a nearby printer (there are printers in
SSO, G23, and other places).
lpr is a basic printing tool for printing text (and it is also clever enough to print most types
of images nowadays). A more sophisticated printing program is a2ps. This produces a nicer
output, and it can recognise different types of text file—including program source code files—
and present the various keywords of the programming language and the program identifiers
in different fonts to help with readability.
Look at the man page for a2ps and use a2ps to print the file
/opt/info/courses/INTRO/SimpleJavaProgram.java
When you collect this print output you will see that a2ps has formatted it nicely. This is a good
way to obtain printouts of your own work, should you wish to.
All students have a printing account which is used to ‘pay’ for their printing. The School has
pre-credited your account with enough credit for you to print all the material needed for your
courses (with some to spare) without having to pay for anything. For administrative reasons,
your initial credit will be £4, and this will be topped-up during the year. The first top-up is
likely to occur during Reading Week.
The printing allowance we give you means that you will be able to to print 500 sides during
the year if you use the double-sided A4 mono option (at 8p per page). Note: the allowance
would only cover 400 sides if you use the A4 single-sided option, at 5p per page, so clearly
printing double-sided is your better option.
4.2.10
Time for a checkup
Check your setup. Now it’s time to check that your CS account’s environment is set up properly. In the earlier introductory labs we got you to make
various changes to the configuration files that determine how your account
behaves (the so-called ‘dotfiles’).
From a terminal, run the command
/opt/teaching/bin/check-my-setup
If you skipped any of the steps in the intro labs, or didn’t quite get things right,
then this script will help you detect any configuration issues that might bite
you later, and will help you fix any problems it finds (if you’re curious about
the script works, use less to check out its contents).
If you don’t understand what the script is telling you to do, please do take this
opportunity to find a member of lab staff to explain things.
94
head
a2ps
Introductory Labs
Blackboard Intro and command line skills
Once you’ve fixed any problems that the script has identified, please re-run
the script to check everything is now okay, and then repeat this process until
the script reports that everything is ‘good’.
4.2.11
Exercises
Here are a number of exercises to experiment with. Use man to find full details of the relevant
commands you need to use. When you have your answers, email them to you personal tutor.
Just send a single email with everything in. If you can’t complete all the exercises, no problem,
just send what you’ve done.
1. As you know, ls -l gives you extra information about files. Skim through the man page
for ls to see what it means. Check the ownership and permissions of your own files. For
more about ownership and permissions, look at the manual pages for the chown and
chmod commands.
Question: Why don’t you own ‘..’ in your home directory?
2. Look at the man entry for rm and find out what would happen if you did cd and then rm
-rf *
WARNING! DO NOT ACTUALLY TRY THIS! We once had a system administrator
who, after logging in as the superuser (that’s a special user called root that has the permission to do anything), typed the above command by accident. What do you think
happened? (Hint: on many Unix systems, the superuser’s home directory is /).
Question: What would it do in your home directory? What would it do if the superuser
made this error?
3. Another useful command is grep, which displays all lines of a file containing a particular
string (in fact, the string can be a pattern with wild-cards and various other things in).
The form for a simple use of grep is
grep [PATTERN] [FILENAME(S)]
This will result in a display of all the lines in the files which contain the given pattern.
A useful file to use for experiments with grep is /usr/share/dict/words, which is a
spelling dictionary. Try to find all words in the dictionary which contain the string ‘red’.
Question: what was the command you used to do this? (Please don’t email your tutor
the results from the command!)
4. Use a suitable pipeline to find out how many words in the dictionary contain the string
‘red’ but not the string ‘fred’. (Hint: The answer to the previous question gives all the
words containing ‘red’, look at the manual page for grep to find out how to exclude
those words containing ‘fred’. The wc (short for ‘word count’) program counts words
(amongst other things). Use pipes to put them all together.)
Question: what was the command you used to do this? How many words did you
find?
You have now finished the lab, but we encourage you to try the exercises contained in the file
/opt/info/courses/INTRO/extras. Don’t worry if you find them tricky—they are.
95
wc
Introductory Labs
4.2.12
Blackboard Intro and command line skills
The end of the beginning
That’s it! You’ve now reached the end of the introductory labs.
What follows next week in your various courses are labs and coursework that will actually
form part of your assessment, and ultimately, your Degree.
If you’re new to Unix/Linux it’s a good idea to spend a bit of time reflecting on and re-reading
through what we’ve already done in order to ready yourself. Make sure you feel comfortable
with the concepts we’ve presented. If something seems a little weird, or hard to follow, spend
a bit of time and go over that bit of the lab script again. Remember, as well as your scheduled
class time in the University, you’re expected to also do some work in your private study time
at home.
And most importantly, if you’re feeling overwhelmed or even just a little concerned about
your understanding of what you’ve met so far, don’t worry. Tell us and we’ll help. Please
don’t suffer in silence—speak to your personal tutor, or email one or all the team (see below)
that created these labs. We’re here to help, and we’re very happy to do that. But before we can,
you need to tell us!
Finally, we want to wish you the best of luck, not just for the coming weeks, but for the coming
semesters and years, in everything you do here in the School.
Steve, Graham, Toby and John.
4.3
Acknowledgements
These notes are largely our own work, but have been inspired in places by previous lab exercises created by Pete Jinks, John Sargeant and Ian Watson. We’re very grateful to Paul Waring,
Alex Day, Alex Constantin, Hamza Mahmud and Ben Mulpeter for test driving and debugging
the exercises.
96
Introductory Labs
Blackboard Intro and command line skills
[email protected]
[email protected]
[email protected]
[email protected]
97
Intro Lab Session 5
Appendix
Contents
5.1
Directories in the Pi’s root filesystem . . . . . . . . . . . . . . . . . . . . . . . 100
5.2
A Map Of Colossal Cave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3
Basic HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.4
5.3.1
Basic page structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3.2
Page structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3.3
Hyperlinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Using USB sticks in Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
These notes are available online at
syllabus.cs.manchester.ac.uk/ugt/COMP10120/labscripts/introappendix.pdf
We suggest you use the online version so that you can follow web links.
September 8, 2017
98
Introductory Labs
Directory
boot
bin
Appendix
Description
Contains the Linux kernel and other low-level packages needed to get
the Pi to boot.
Contains the binary executables for basic commands such as ls and
pwd.
dev
This is a virtual directory that represents devices connected to the Pi as
though they were files that you can read from and write to.
etc
Contains configuration files used by various programs, and also the
names and encrypted passwords of users
home
Each user gets their own subdirectory of home.
lib
This is where libraries are stored; these are bits of code that are shared
between several programs.
lost+found
If something bad happens and the system crashes half way through
doing something, it will put a copy of files that it knows are in a broken
state here.
When you mount removable storage devices such as USB memory
stickets, they will appear as filesystems here.
media
mnt
This directory is used to mount storage devices.
opt
When you install optional software that’s not considered part of the
operating system, it usually ends up here.
proc
Like dev, this is a virtual directory. This one contains accounting information about the various processes that are running on your Pi.
selinux
Contains utility files relating to Security Enhance Linux.
sbin
This contains special executable binary files associated with system
maintenance.
sys
Various files needed by the operating system.
tmp
Many programs need to create temporary files as part of their execution; they go here, and get deleted when the system reboots.
usr
User-accessible programs and bits of configuration.
var
Another virtual directory, used by programs to store variables.
Table 5.1: Standard Linux system directories.
99
Introductory Labs
5.1
Directories in the Pi’s root filesystem
5.2
A Map Of Colossal Cave
Appendix
This map of Colossal Cave is reproduced here by kind permission of its author, Mari Michaelis.
This is the ‘spoilers’ version of the map, and contains clues as to how to solve the various puzzles in the game. If you want to play the game for real, you probably should make your own
map, or at least use the spoiler-free version of the map available at www.spitenet.com/
cave.
100
Introductory Labs
5.3
Appendix
Basic HTML
HTML is a markup language used for creating web pages. It encodes the structure and content of a page, and it’s interpreted by a web browser in order to display the page. This section
gives a very quick overview of a few basic HTML features, and omits a lot of stuff, most notably CSS which is used to style the visual appearance of the content encoded by HTML.
You’ll meet CSS properly, later in the course.
W
W
For a complete HTML tutorial, see, for example, www.w3schools.com/html.
5.3.1
Basic page structure
Here’s the basic structure of a webpage.
<html>
<head>
<body>
Hello world!
</body>
</head>
</html>
Each construction in angle-brackets, such as <body> is called a ‘tag’. Most tags come in in
pairs, as in the above example, where <body> and </body> delimit the ‘body’ of the page,
which in this case it’s simply the text ‘Hello World!’.
5.3.2
Page structure
Let’s expand the body of the page, first to introduce some section headings, and add some
paragraphs:
<body>
<h1>This is a level-1 section heading</h1>
<p>Hello world! (paragraph 1) </p>
<p>This is paragraph 2 </p>
</body>
The <h1> tag specifies the start of a new section. The browser will render this as larger-thanusual text, and add some vertical space around it. The <p> tag says ‘start a new paragraph’,
and </p> says ‘end the paragraph’, which again the browser renders with a bit of vertical
space. You probably get the idea.
Here’s how to make a bulleted list (<ul>| stands for ‘unordered list’; <li> means ‘list item’):
My hobbies are:
<ul>
<li>astronomy</li>
<li>gastronomy</li>
101
Introductory Labs
Appendix
<li>hippogastronomy</li>
</ul>
You can make a numbered list with <ol>...</ol>.
5.3.3
Hyperlinks
One of the most powerful features of HTML is of course to create hyperlinks to other pages,
using the <a> tag, as follows:
<a href="web page address">text for link</a>.
For example:
My hobby is writing for <a href="http://en.wikipedia.org/">wikipedia</a>.
5.4
Using USB sticks in Linux
Using a USB drive with the Pi presents an interesting challenge. If you are running the graphical LXDE environment, then you can just plug a USB Drive into one of the USB ports, and a
handy filebrowser window will appear, allowing you to copy files on and off the drive, and
then eject it when you’re done much as you would do in Windows or OS X. However, sometimes you will need to access USB devices from the command line, without this automatic
feature.
Fortunately, it’s also possible to mount USB devices using the command line. Unfortunately,
the process of mounting a USB device ‘manually’ is a little fiddly. But follow these instructions
and all will be well.
The first thing you’ll need to do is to find out what the Pi thinks your USB device is called. To
do this, we’ll need to use the tail command to look at a system log and spot the name of the
device when you plug it in. Type:
tail -f /var/log/messages
and then plug in your USB drive. You’ll see a series of lines appear, containing text like ’New
USB device found’, and after these a line which says ‘sda: sda1’ (actually ’sda1’ may be a
different number on your Pi, but unless you’ve connected other USB storage devices it will
most-likely be sda1). Note this number down, you will need it in a moment.
The tail command behaves a little like less in that it displays the contents of a file (in this
case, one of the systems log files); the difference is that tail allows you to see the last few lines
of a file instead of starting from the beginning. The -f switch to tail tells it to ‘follow’ a file,
that is to continue to watch the file and to display any new lines that get appended to the end
of that file (without the switch, tail just displays the lines and then quits).
Now that you have the sda number from the log file, quit tail using <ctrl>c.
102
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement