Using UNIX Bob Eager Using UNIX 1 Introduction

Using UNIX Bob Eager Using UNIX 1

Introduction � we shall, for convenience, use the UNIX™ name to cover all systems that look like UNIX, as well as those which are officially entitled to use the name � recap: � in use at Kent since 1975 � a major influence on many systems � in heavy use worldwide (Linux, Free. BSD, Mac. OSX, etc. ) � a worthwhile thing to know about – a marketable skill � useful for all Kent CS students! Using UNIX 2

The UNIX User Interface � the original UNIX systems were designed for use on hardcopy devices such as teletypes (in extremis) and teletypewriters, as well as simple video terminals (“glass teletypes”), connected via a slow serial line � as such, the only user interface was the command line � a simple textual command prompt � short commands, often cryptic, with minimal feedback � slow typists (less to type) � slow output from terminal (less waiting for messages to type out) � most UNIX systems were multi user, because hardware was expensive � later, with cheaper hardware, came: � single user UNIX workstations � graphical interfaces Using UNIX 3

Why use the command line? � you may wonder why the command line interface still exists… � it’s the underlying base for everything else � it’s always there; the only thing that’s available when there are serious problems (e. g. graphics driver errors) � it doesn’t limit what you can do; with a graphical interface, you’re limited to what the menu items let you do, and some things can only be done from the command line � it’s productive; in most cases you can accomplish a great deal more, much more quickly, with the command line � it allows automation; you can put a load of commands into a file, and have them all run as a sequence, without any interaction � you can use it to access remotely over a low bandwidth connection, to fix or maintain a system Using UNIX 4

Philosophy � the original UNIX philosophy was to use lots of small programs, each doing one task, but doing it well � e. g. : � cat – just joins files together (short for concatenate) � cut – just extracts fields from lines in files � date – gives full details of the current date and time � join – joins lines of two files � etc. � then, if a command doesn’t do quite what we want, we use another command to change or reformat what came out of the first one � instead of using bloated programs for different tasks, which often repeat similar functionality in subtly different ways! Using UNIX 5

Shells � UNIX was based on a multi-user system called MULTICS, and was originally single user – hence the bad pun! � the original model was a system with a number of “layers”, the outermost one being the user interface (the command prompt) � for obvious reasons, the outermost layer was called the shell, and the original shell program was called sh Using UNIX 6

� the shell is just a program, and there are many different shells available – the war between different shell users rivals the language and editor (and Linux distro) wars… � files containing shell commands are known as shell scripts or shell programs, and can be quite complicated � the shell “language” usually includes for loops, if statements, case statements, variables, etc. � shell scripts can be very, very powerful, but they are not the easiest thing to write (or even read…) Using UNIX 7

� many shells are variations on, and developments of, the original shell shipped with Sixth Edition UNIX in 1975 � this was known as sh � variants of this are many, including a development of Steve Bourne’s enhancements, now known as bash (the Bourne Again Shell) [groan] � another common shell is the C shell, csh � this resembles the C programming language � many people feel that sh is better for complicated scripts, but csh is better for use at the command line � although a lot of the csh features have been copied in newer shells such as bash Using UNIX 8

Logging in � if you’re not using a graphical user interface, the login prompt looks like this: login: � you log in by first typing your login name; the term originated on UNIX, but is now used more widely � it’s often abbreviated (incorrectly perhaps) to login � you’re then prompted for a password: Password: � if this is correct, you are logged in and the shell is started; the first thing it does (after introductory messages) is issue a command prompt: $ � that was a prompt from sh; you get a different one from csh: % � you can change the prompt if you wish (and indeed the shell) Using UNIX 9

The UNIX ‘process model’ � in UNIX, any activity or task is known as a process � usually, a process exists just to start one program, and then run it � when you log in, UNIX creates a process for you and tells it to run your chosen shell, connected to your display and keyboard � it’s the running of that program that generates the command prompt � when you type the name of a program to the shell, it usually creates another process to run that program – it then waits until the program finishes, after which it prints the prompt again $ ls. . $ � when the program finishes, its process is destroyed forever Using UNIX 10

� when you tell the shell to stop, you are logged out � this model makes it easy to do “clever” things: � run the program but issue another command prompt straight away � in other words, run the command “in the background” � example: $ processbigdatabase & $ � the & at the end tells the shell not to wait for completion of the process it started � there are facilities for monitoring and controlling many background jobs, which we won’t examine here, but the commands fg, bg and jobs are relevant � these may be covered in the classes if there is time Using UNIX 11

� run more than one program at the same time not useful in its own right, but very good if you want to “connect” programs together � as we shall see soon, this is part of the underlying ethos of UNIX � example: $ program 1 | program 2 � which sends the output of program 1 to the input of program 2 � this is known as a pipeline; the connections (pipes) are specified using the | symbol � more about these later � Using UNIX 12

Command structure � commands have an ‘economical’ structure � the command name � some optional flag arguments � some non-flag arguments – again optional in many cases � arguments are not disagreements (!), but details that describe what you want the command to do � flag arguments are used to modify the way the command works � non-flag arguments are commonly file names, directory names, etc. but may be other things � by convention, flag arguments usually appear first Using UNIX 13

� let’s look at an example of a simple command � the ls command can list the names of all the files in a directory: $ ls Mail bin essay. doc friends. txt $ � we can add the –l flag to get a ‘long’ detailed listing $ ls –l drwxr-xr--rwxr--r--rwxr--r-$ 1 1 rde rde justso 10657 1024 29650 50347 Oct Oct 30 30 23: 57 Mail bin essay. doc friends. txt � this includes permissions, owner, group, size, date… � we can also include a file or directory name to limit the output: $ ls –l essay. doc -rwxr--r-1 rde justso Using UNIX 29650 Oct 30 23: 57 essay. doc 14

� to differentiate flags from other arguments, they are usually preceded by a – character � there are special arrangements if you start a filename with a – � you can often combine flags, like this: $ ls –l –a which can be replaced by: $ ls –la � most commands accept multiple non-flags arguments and just work on all of them: $ ls –l Mail essay. doc � some commands just have a weird syntax and don’t obey these conventions at all! $ dd if=input. txt of=/dev/null bs=3 count=1 Using UNIX 15

Some sample commands � ls: list names of one or more files or directories � who: see who is logged in � pwd: print the name of the current (“working”) directory � rm: remove a file � cp: copy one or more files � mkdir: make a new directory (i. e. folder) � rmdir: remove a directory � cat: concatenate files together � man: display the “manual page” for a command � e. g. : man ls � there are hundreds of commands in the basic system, and you can add more, of course Using UNIX 16

Files � files are just ordered collections of bytes � file names can be pretty well anything you like, but: � avoid peculiar characters as they can be a pain to use (they probably mean something special) � spaces in filenames need special treatment, e. g. : ls –l ″My Documents″ (if the quotes were omitted, ls would treat “My” and “Documents” as two separate arguments) � upper and lower case characters are distinct (unlike Windows), so files called Bob and bob are different… � the convention is to use mainly lower case characters � the / character is used as a path separator (see later) Using UNIX 17

Command I/O redirection � one of the most powerful concepts in UNIX is command I/O (input/output) redirection � all processes (i. e. all programs) in UNIX start off with three predefined input or output streams, through which they can read or write bytes: � the standard input stream is where, by default, the program will read any input � the standard output stream is where, by default, the program will write any output � the standard error stream is where, by default, the program will write any error messages � in Java, these correspond respectively to System. in, System. out, and System. err Using UNIX 18

� in its simplest use, the cat command copies its standard input to its standard output, so: $ cat hello world ^D $ � what happened here? � we invoked the cat command � we typed a line of input (hello world) � cat copied that line to its standard output (the screen) [not necessarily at once] � we typed a Control-D character, to tell cat we’d finished � it seems that standard input is the keyboard, and standard output is the screen – yes, and standard error is also the screen � that’s because, by default, programs use the same I/O as the shell Using UNIX 19

� the power lies in being able to redirect any of these � to redirect the standard input, we use the < character followed by a filename: $ cat < myfile which would copy myfile to the standard output (i. e. display it) � to redirect the standard output, we use the > character followed by a filename: $ cat < myfile > mynewfile (of course, there actually better ways of copying files) � in fact, cat will copy any files given as arguments to its standard output, so we could just use: $ cat myfile > mynewfile Using UNIX 20

� we can even redirect standard error, using the sequence 2> (not terribly obvious, but’s that’s just the UNIX charm…) � let’s try to look at a nonexistent file: $ cat missingfile cat: missingfile: no such file or directory $ � so, we got an error message; let’s do it again, and redirect the message: $ cat missingfile 2> xyzzy $ � this time, cat was silent – it put the message into the file xyzzy. Let’s check: $ cat xyzzy cat: missingfile: no such file or directory $ � this is all very useful – believe it or not… Using UNIX 21

� I/O redirection gives us lots of useful ways to use programs � many programs will use standard input if they are not given a “file” argument � redirection of standard error means that error messages don’t get mixed up with the output from the program � redirection of all three streams means that programs can run in the background without messing up other work using the keyboard and screen � but we get even more power by interconnecting programs using pipes Using UNIX 22

Pipes � pipes are one of the most important UNIX concepts � they allow programs to communicate with each other (can you say inter process communication? ), and we can use them when we write programs � however, the shell will provide these connections, if asked � there is a useful program called more, which copies its standard input to its standard output, stopping after every screen full (it can accept filenames too, just as cat can) � if we had a directory containing lots of files, we could list it a screen at a time with: $ ls –l | more � the | character represents a pipe, connecting standard output of ls to standard input of more Using UNIX 23

� you can build lots of really useful things using pipes; for example, if you had three chapters of a book and you wanted to display the numerous spelling errors on the screen: $ cat chap 1 chap 2 chap 3 | spell | more � here, we used two pipes to connect three programs � a useful program is tee, a “pipe fitting” – it provides a “tee junction” that sends the same output to a file, and to standard output: $ cat chap 1 chap 2 chap 3 | spell | tee errors | more � here, we took a copy of the errors in the file errors Using UNIX 24

File Structure � the UNIX file system is different from many others (e. g. Windows) � in other systems, it is common to have “devices” or “drives” for each separate piece of storage hardware (e. g. drive letters in Windows) � instead, UNIX represents all disks that are attached to the machine (including network shares) as part of a single giant file system � the file system consists of files and directories (directories are similar to folders on Windows – they contain files) � the file system has a tree structure, and the top of this giant “tree” is known as / (pronounced “slash” or “root”) � disks and shares can be attached into this tree at arbitrary locations this is known as mounting a file system; typically this requires the user named root (the UNIX equivalent of the Windows Administrator user) to do this, for security reasons Using UNIX 25

� here’s a simplified example of a typical UNIX file system at Kent: / … courses projweek … local … … cut cur 022 … share mounted disk … … usr home … … … cut 999 network share Using UNIX 26

� when you log into a UNIX machine you will start off “in” your home directory � you can then move around the file system as you wish, using various UNIX commands � at all times, the directory you are currently in is known as your current working directory, often abbreviated to current directory or working directory (you can get a reminder with the pwd command) � the location of any file in the file system can be described by its path � a path is a list of directories, separated by /, followed by the name of the file � there are two types of paths, absolute and relative: � absolute paths start with a /, and describe the complete path from the top (“root”) of the file system to the file � relative paths do not have a / at the beginning, but instead they describe a path to the file from the current directory Using UNIX 27

� the best way to learn about this is to do it, so the classes will give you lots of practice at this! Using UNIX 28

Summary � the UNIX command line is a powerful tool � you will use it even when you have a graphical interface, as it’s much more flexible � the classes are designed to give you practice and further instruction in using the command line (because anyone can use a graphical interface, after all…. ) � if you haven’t already done it, this will save you time in your first class; note that you’ll need your student number: http: //www. cs. kent. ac. uk/systems/newuser/ � more stuff here: http: //unixhistory. tavi. co. uk � other interesting stuff: http: //www. bobeager. uk Using UNIX 29