Download Lecture 1 - Concepts of the UNIX Operating System

UNIX COMP-145
LECTURE 1:
CONCEPTS OF THE UNIX OPERATING SYSTEM
SOURCE:
S. DAS, “YOUR UNIX: THE ULTIMATE GUIDE”, 2ND EDITION, MCGRAW HILL, 2006
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
1
CONTENTS
•
•
•
•
•
•
•
•
•
•
•
11/19/2009 rwj
WHY AN OPERATING SYSTEM (OS)
HOW A PROGRAM RUNS ON A COMPUTER
RUNNING MULTIPLE PROGRAMS
KEY CONCEPTS
UNIX ARCHITECTURE: THE KERNEL
UNIX ARCHITECTURE: THE SHELL
UNIX FRAGMENTATION
WHY UNIX COMMANDS ARE NONINTERACTIVE
STRUCTURE OF A COMMAND
TYPES OF COMMANDS
HOW THE SHELL DETERMINES THE COMMAND TO RUN
BROOKDALE COMMUNITY COLLEGE
2
WHY AN OPERATING SYSTEM (OS)
• OS INTERACTS WITH HARDWARE AND MANAGES PROGRAMS.
• PROGRAMS NOT EXPECTED TO KNOW WHICH HARDWARE THEY WILL RUN ON.
• MUST BE POSSIBLE TO CHANGE HARDWARE WITHOUT CHANGING THE PROGRAMS.
• PROGRAMS CAN’T MANAGE THEMSELVES.
• OS PROVIDES A SAFE ENVIRONMENT FOR PROGRAMS TO RUN.
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
3
IMPORTANT ORGANIZATIONS & STANDARDS FOR UNIX
• THE OPEN GROUP
– Owns UNIX trademark
• POSIX – PORTABLE OPERATING SYSTEM INTERFACE [FOR UNIX]
– Defines standardized UNIX computing environment
– OSs based on UNIX can claim conformity
– Specification Issue 6
• XPG – X-OPEN PORTABILITY GUIDE
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
4
HOW A PROGRAM RUNS ON A COMPUTER
• OS LOADS PROGRAM FROM DISK AND ALLOCATES MEMORY AND CPU.
• INSTRUCTIONS IN PROGRAM ARE RUN ON CPU AND OS KEEPS TRACK OF
LAST INSTRUCTION EXECUTED.
• IF PROGRAM NEEDS TO ACCESS THE HARDWARE, OS DOES THE JOB ON
ITS BEHALF.
• OS SAVES THE STATE OF THE PROGRAM IF PROGRAM HAS TO LEAVE CPU
TEMPORARILY.
• OS CLEANS UP MEMORY AND REGISTERS AFTER PROCESS HAS
COMPLETED EXECUTION.
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
5
RUNNING MULTIPLE PROGRAMS
• MULTIPROGRAMMING: MULTIPLE PROGRAMS CAN BE IN MEMORY.
• MULTIUSER:
MULTIPLE USERS CAN RUN PROGRAMS.
• MULTITASKING:
ONE USER CAN RUN MULTIPLE PROGRAMS.
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
6
KEY CONCEPTS
• EVERYTHING IN THE SYSTEM IS REPRESENTED AS A FILE.
• WORK GETS DONE BY PROCESSES
 THE PROGRAM OF EXECUTION IN FOREGROUND & BACKGROUND
•
WORKLOAD SHARED BY TWO SEPARATE PROGRAMS
(KERNEL AND SHELL)
 KERNEL – THE CORE OS
 SHELL – INTERFACES WITH USER PROGRAM & OS.
INTERPRETED SET OF COMMANDS IN AN ENVIRONMENT, E.G., A LOGIN SESSION
•
•
KERNEL USES SYSTEM CALLS TO DO MOST OF THE WORK.
ALL UNIX SYSTEMS USE THE SAME SYSTEM CALLS.
11/19/2009 rwj
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
BROOKDALE COMMUNITY COLLEGE
7
7
UNIX ARCHITECTURE: THE KERNEL
•
•
•
•
•
11/19/2009 rwj
PROGRAM ALWAYS RESIDES IN MEMORY, I.E., THE OS.
HAS DIRECT ACCESS TO THE HARDWARE.
HANDLES FILE I/O.
MANAGES PROCESSES.
ONLY ONE COPY SHARED BY ALL USERS.
BROOKDALE COMMUNITY COLLEGE
8
UNIX ARCHITECTURE: THE SHELL
•
•
•
•
•
A PROGRAM OR COMMAND INVOKED ONLY WHEN THE USER LOGS IN.
ACCEPTS USER INPUT, EXAMINES AND REBUILDS THE COMMAND LINE.
MAKES CALLS TO THE KERNEL FOR ALL OTHER FUNCTIONS.
AT LEAST ONE SHELL IS INVOKED BY EVERY USER.
USER HAS A CHOICE OF SHELLS.
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
9
UNIX’S FRAGMENTED EVOLUTION
• SYSTEM V FROM AT&T (SVR4)
• BSD UNIX FROM BERKELEY
• LINUX WITH HELP FROM GNU
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
10
WHY UNIX COMMANDS ARE NON-INTERACTIVE
•
•
•
•
•
COMMAND MAY TAKE INPUT FROM THE OUTPUT OF ANOTHER
COMMAND.
MAY BE SCHEDULED TO RUN AT SPECIFIC TIMES (E.G., at & cron).
USER INPUT CAN ALSO BE PROVIDED THROUGH COMMAND LINE
ARGUMENTS.
COMMAND ARGUMENTS NEED NOT BE KNOWN IN ADVANCE.
ALLOWS DESIGNING OF APPLICATIONS THAT DETERMINE THEIR OWN
BEHAVIOR BY READING CONFIGURATION FILES.
NOTES:
1. Many UNIX commands (called filters) possess an unusual property in that the output of one command can be connected to
the input of another. In this way, pipelines of two or more commands can be set up to handle complex text manipulation
tasks. You can’t have a pipeline of interactive commands.
2. The behavior of some applications like the shell is mainly determined by settings placed in a configuration file. The
application reads this file on startup and then knows how to behave. A major advantage of noninteractivity.
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
11
STRUCTURE OF A COMMAND
e.g. ls
-l -u -t chap01
• COMMAND FILENAMES NEED NO SPECIFIC EXTENSIONS.
• A COMMAND’S BEHAVIOR IS DETERMINED BY ITS ARGUMENTS AND OPTIONS.
• COMMAND AND ARGUMENTS MUST BE SEPARATED BY WHITESPACE.
• GENERALLY POSSIBLE TO COMBINE MULTIPLE OPTIONS INTO A SINGLE ONE
(like ls -l -u -t == ls -lut)
• ORDER OF COMBINING IS GENERALLY NOT IMPORTANT
(like ls -lut == ls -utl)
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
12
TYPES OF COMMANDS
•
EXTERNAL PROGRAM ON DISK WHICH COULD BE
• A BINARY EXECUTABLE (WRITTEN IN C, C++).
• A SCRIPT FILE (LIKE A SHELL OR PERL SCRIPT).
• INTERNAL COMMAND OF THE SHELL WHICH COULD BE
• A BUILT-IN (LIKE cd, pwd, ETC.)
• AN ALIAS DEFINED BY THE USER THAT INVOKES THE DISK OR
INTERNAL VERSION IN A SPECIFIC MANNER.
11/19/2009 rwj
BROOKDALE COMMUNITY COLLEGE
13
HOW THE SHELL DETERMINES THE COMMAND TO RUN
• IF COMMAND IS INVOKED WITH A PATHNAME (LIKE /bin/echo), THE
SHELL RUNS PROGRAM AT THE SPECIFIED LOCATION.
• IF COMMAND IS INVOKED WITHOUT A PATHNAME, THE SHELL FIRST
CHECKS WHETHER IT IS AN ALIAS OR BUILT-IN:
• IF ALIAS OR BUILT-IN, THE SHELL RUNS IT WITHOUT LOOKING IN DISK.
EXAMPLES OF BUILT-IN COMMANDS: type, whatis
AND
which
NOTE: THESE COMMANDS CAN HELP LOCATE OTHER COMMANDS AND DETERMINE WHICH COMMANDS ARE BUILT-IN
• IF NOT, THE SHELL LOOKS AT THE PATH VARIABLE FOR DIRECTORIES
WHERE THE COMMAND MAY RESIDE.
$ echo $PATH
11/19/2009 rwj
WHERE
$echo
IS A SHELL, $path INDICATES INPUT VARIABLE
BROOKDALE COMMUNITY COLLEGE
14