Operating Systems 2022F Lecture 2

Video

Video from the lecture given on September 13, 2022 is now available:
Video is also available through Brightspace (Resources->Zoom meeting->Cloud Recordings tab)
Textbook Readings

Topics

UNIX shells, shell basics
processes
- basic concept
- viewing
files & file permissions
Environment variables & shell variables
Signal & process control (basics)
Notes

Lecture 2
---------

What is a shell?
 - first, it is a program communicating over a "serial port"
    - virtual nowadays
    - really, a bytestream, but that's always just an interpretation of
      a series of bits

A modem is a device for connecting a serial port to a phone line
  - basically, a serial line extender over the phone network

Why bytes?
 - 8 bits are enough to encode text
   (well, 7 bits, extra bit was used for contol traditionally)
 
Today we use unicode, but before that there was ASCII
 - translation between 7-bit patterns to characters

No intrinsic reason to use bytes
 - except it is a power of 2, and that works well when translating from binary

8 = 2^3
16 = 2^4
256 = 2^8
1024 = 2^10
65536 = 2^16

utf8 is backwards compatible with ASCII (lower 7 bits is the same)


Past terms for computers
 - mainframe  <--- these came first, biggest, most expensive
                   STILL AROUND
 - minicomputer
 - workstation
 - personal computer (PC)


So when you interact with a shell in a terminal, you
 - are interacting with a virtual device that is emulating
   something close to a VT100
 - it is also emulating a serial connection (with all of those
   idiosyncracies)


UNIX-like systems have a "teletype" abstraction, tty, which is what terminal emulation programs interface with
  - faking a connection over a serial port

So, what are we REALLY interacting with when we interact with a shell?
  - the terminal is just the interface

*A shell is a program used to run other programs*
 - many shells are programmable
 - many have various nice UI tweaks (command history, command line editing)
But the purpose is to run other programs


Most commands that you type in a shell are actually running separate programs

In CS terms, your graphical desktop is a "graphical shell", another kind
of program used to run other programs
 - but really, a modern GUI is a collection of programs that work together,
   very complex
 - a shell in a terminal is, fundamentally, very simple

It had to be simple, it was supposed to work on computers from 50 years ago!
 - computers back then were rather pathetic in their capabilities
 - so, you keep things simple


When you run an external command in a shell, it is running a separate binary
Internal commands are part of the shell program
 - shells vary in what commands/functionality is built in
 - bash has lots built in

Why build functionality into the shell itself?
 - efficiency
 - convenience
 - necessity

UNIX directory structure
 - bin: directory of binaries (executable programs)
 - lib: libraries (code that is incorporated into programs,
                   either at build or runtime)
 - src: source code
 - sbin: binaries used by the system/administrators
 - include: C header files
 - local: locally-installed software (not so significant on Linux systems)
 - home: user home directories
 - var: "variable" data, place for the system to put data generated at
   runtime/loaded from the network
 - /proc and /sys: information on the running system (kernel)
 - /run: info on currently running processees
 - /tmp: temporary files
 - /root: root user (admin user) home directory
 - /usr: "user" directory, historical artifact at this point
     - no clear difference between /bin and /usr/bin
       except most go into /usr/bin
 - /etc: configuration information
 - /dev: device files (we'll talk about these later)

Common commands
 - pwd: present working directory
 - cd: change directory
 - ls: list files
 - whoami: what is the current user
 - who: what users are currently using the system
 - ps: list running processes
 - top: interactive view of running processes
    - htop: modern version of top
 - pstree: see a hierarchical view of processes
 - less: view a text file (better version of more)
    - you can quit less with the "q" key
 - man: manual, look up something in it
 - grep: search input for a given pattern (useful with "|")


Some programs are "standard", others aren't
 - top is standard
 - htop isn't standard

What is and isn't standard is a historical artifact

But what is fundamental is how programs are run
 - when you type a command and the shell determines it is external, it does the following:
   - it creates a new process
   - the new process loads & runs the selected program

What is a process?
 - abstraction that allows us to share the computer resources between multiple programs
    - each program runs in its own process
    - a given program can be running in multiple processes

 
shell: a program like bash, that takes input to run other programs
terminal: a "device"/program for interacting with text-mode programs
   (emulates something like a vt100)

kill sends a signal to a process
 - signals are most commonly used to terminate a process
 - type "man 7 signal" to see a list of all signals

SIGTERM tells a process, please terminate, and the process can say no
  - also can choose to clean up before terminating
SIGKILL tells the system to terminae the process, the process doesn't
  get a say in it (it can't ignore it)


Really, the shell is an interface to the kernel
 - you can't interact with the kernel directly
 - our focus this term will be on what the kernel is
 - "Linux" is really the "Linux kernel"

What programs are involved when I connect to openstack?  MANY
Here are some:

On my machine, running Ubuntu as well
 - gnome-terminal  <--- terminal emulation program
 - ssh <--- connect to remote system using encryption
 - Wayland <--- render a graphical desktop

On the openstack virtual machine
 - sshd <--- receive remote connections using encryption
 - login <--- authorize remote connections, set things up
 - bash <--- the shell


So, why don't I just give you a book which has all the info I want you to learn?
 - well, I've never found a book like that
 - even if I did, I'd probably still mention things that weren't in it
 - besides, that's not the point
 - instead, I want you to learn *how to learn* about systems
   - pose questions
   - find resources to get answers
      - online/books/man pages
      - experiments <--- especially this