1. U NIX C OMP -145 L ECTURE 1: C ONCEPTS OF THE UNIX O PERATING S YSTEM S OURCE : S. D AS, “Y OUR U NIX : T HE ULTIMATE G UIDE ”, 2 ND E DITION, M C G RAW H ILL, 2006 BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj1

2. C ONTENTS W HY AN O PERATING S YSTEM (OS) H OW A P ROGRAM R UNS ON A C OMPUTER R UNNING M ULTIPLE P ROGRAMS K EY C ONCEPTS UNIX A RCHITECTURE : T HE K ERNEL UNIX A RCHITECTURE : T HE S HELL UNIX F RAGMENTATION W HY UNIX C OMMANDS A RE N ONINTERACTIVE S TRUCTURE OF A C OMMAND T YPES OF C OMMANDS H OW THE S HELL D ETERMINES THE C OMMAND TO R UN BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj2

3. W HY AN O PERATING S YSTEM (OS) OS INTERACTS WITH HARDWARE AND MANAGES PROGRAMS. P ROGRAMS NOT EXPECTED TO KNOW WHICH HARDWARE THEY WILL RUN ON. M UST BE POSSIBLE TO CHANGE HARDWARE WITHOUT CHANGING THE PROGRAMS. P ROGRAMS CAN ’ T MANAGE THEMSELVES. OS PROVIDES A SAFE ENVIRONMENT FOR PROGRAMS TO RUN. BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj3

4. BROOKDALE COMMUNITY COLLEGE4 I MPORTANT O RGANIZATIONS & S TANDARDS FOR UNIX T HE OPEN GROUP T HE OPEN GROUP – Owns UNIX trademark POSIX – P ORTABLE O PERATING S YSTEM I NTERFACE [ FOR UNIX] – Defines standardized UNIX computing environment – OSs based on UNIX can claim conformity – Specification Issue 6 Specification Issue 6 XPG – X-O PEN P ORTABILITY G UIDEX-O PEN P ORTABILITY G UIDE

5. H OW A P ROGRAM R UNS ON A C OMPUTER OS LOADS PROGRAM FROM DISK AND ALLOCATES MEMORY AND CPU. I NSTRUCTIONS IN PROGRAM ARE RUN ON CPU AND OS KEEPS TRACK OF LAST INSTRUCTION EXECUTED. I F 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. BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj5

6. R UNNING M ULTIPLE P ROGRAMS M ULTIPROGRAMMING : M ULTIPLE PROGRAMS CAN BE IN MEMORY. M ULTIUSER : M ULTIPLE USERS CAN RUN PROGRAMS. M ULTITASKING : O NE USER CAN RUN MULTIPLE PROGRAMS. BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj6

7. K EY C ONCEPTS E VERYTHING IN THE SYSTEM IS REPRESENTED AS A FILE. W ORK GETS DONE BY PROCESSES  T HE PROGRAM OF EXECUTION IN FOREGROUND & BACKGROUND W ORKLOAD SHARED BY TWO SEPARATE PROGRAMS ( KERNEL AND SHELL )  K ERNEL – THE C ORE OS  S HELL – I NTERFACES WITH USER PROGRAM & OS. I NTERPRETED SET OF COMMANDS IN AN ENVIRONMENT, E. G., A LOGIN SESSION K ERNEL USES SYSTEM CALLS TO DO MOST OF THE WORK. A LL UNIX SYSTEMS USE THE SAME SYSTEM CALLS. BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj7 BROOKDALE COMMUNITY COLLEGE7

8. UNIX A RCHITECTURE : T HE K ERNEL P ROGRAM ALWAYS RESIDES IN MEMORY, I. E., THE OS. H AS DIRECT ACCESS TO THE HARDWARE. H ANDLES FILE I/O. M ANAGES PROCESSES. O NLY ONE COPY SHARED BY ALL USERS. BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj8

9. UNIX A RCHITECTURE : T HE S HELL A PROGRAM OR COMMAND INVOKED ONLY WHEN THE USER LOGS IN. A CCEPTS USER INPUT, EXAMINES AND REBUILDS THE COMMAND LINE. M AKES CALLS TO THE KERNEL FOR ALL OTHER FUNCTIONS. A T LEAST ONE SHELL IS INVOKED BY EVERY USER. U SER HAS A CHOICE OF SHELLS. BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj9

10. UNIX’ S F RAGMENTED E VOLUTION S YSTEM V FROM AT&T (SVR4) BSD UNIX FROM B ERKELEY L INUX WITH HELP FROM GNU BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj10

11. W HY UNIX C OMMANDS A RE N ON - INTERACTIVE C OMMAND MAY TAKE INPUT FROM THE OUTPUT OF ANOTHER COMMAND. M AY BE SCHEDULED TO RUN AT SPECIFIC TIMES ( E. G., at & cron ). U SER INPUT CAN ALSO BE PROVIDED THROUGH COMMAND LINE ARGUMENTS. C OMMAND ARGUMENTS NEED NOT BE KNOWN IN ADVANCE. A LLOWS 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. BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj11

12. S TRUCTURE OF A C OMMAND e.g. ls -l -u -t chap01 C OMMAND FILENAMES NEED NO SPECIFIC EXTENSIONS. A COMMAND ’ S BEHAVIOR IS DETERMINED BY ITS ARGUMENTS AND OPTIONS. C OMMAND AND ARGUMENTS MUST BE SEPARATED BY WHITESPACE. G ENERALLY POSSIBLE TO COMBINE MULTIPLE OPTIONS INTO A SINGLE ONE (like ls -l -u -t == ls -lut ) O RDER OF COMBINING IS GENERALLY NOT IMPORTANT (like ls -lut == ls -utl ) BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj12

13. T YPES OF C OMMANDS E XTERNAL PROGRAM ON DISK WHICH COULD BE A BINARY EXECUTABLE ( WRITTEN IN C, C++). A SCRIPT FILE ( LIKE A SHELL OR PERL SCRIPT ). I NTERNAL 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. BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj13

14. H OW THE S HELL D ETERMINES THE C OMMAND TO R UN I F COMMAND IS INVOKED WITH A PATHNAME ( LIKE /bin/echo ), THE SHELL RUNS PROGRAM AT THE SPECIFIED LOCATION. I F COMMAND IS INVOKED WITHOUT A PATHNAME, THE SHELL FIRST CHECKS WHETHER IT IS AN ALIAS OR BUILT - IN : I F ALIAS OR BUILT - IN, THE SHELL RUNS IT WITHOUT LOOKING IN DISK. E XAMPLES OF BUILT - IN COMMANDS : type, whatis AND which NOTE: T HESE COMMANDS CAN HELP LOCATE OTHER COMMANDS AND DETERMINE WHICH COMMANDS ARE BUILT - IN I F NOT, THE SHELL LOOKS AT THE PATH VARIABLE FOR DIRECTORIES WHERE THE COMMAND MAY RESIDE. $ echo $PATH WHERE $ echo IS A SHELL, $path INDICATES INPUT VARIABLE BROOKDALE COMMUNITY COLLEGE11/19/2009 rwj14