May 23
Review the basics
Early computers usually ran batch jobs: you would write your program and then submit it. Later (hopefully minutes later but sometimes hours) you'd discover your program ran (possibly unsuccessfully), and would collect your output.
Debugging was hard.
Often you would write your program on IBM cards and submit your job by handing a box of your cards to a machine operator across a counter. Your output would be printed. This system was still in use at Loyola when I came here in 1982, when essentially all computing here was done on one IBM mainframe running the System/370 operating system. (I refused to have anything to do with cards.)
Serious computer users disliked this, and there were interactive time-sharing operating systems. Even the IBM mainframe got time sharing, early on.
The Multics project was intended to build the ultimate time-sharing operating system. It began in 1964, as a joint project by MIT, GE, AT&T and others. The operating system was certainly reasonably successful, but there were Issues, and Bell Labs pulled out in 1969.
Ken Thompson was a Bell Labs employee who worked on Multics, and after the pullout he began a new operating system which he called Unix, along with Dennis Ritchie and others. The idea of the name was that Multics tried to do MULtiple things, and Unix would do one thing well. Unix was heavily influenced by the design of Multics.
There was no "batch mode" in Unix, ever. Everything started through interactions with a terminal, connected via a serial line, and which ran a shell program that displayed what you were typing and what the computer's responses were on a screen. (You could still run "background" jobs.) The shell also launched commands that you typed.
It is not entirely clear to me exactly when the first Unix system booted successfully, but the Unix "epoch date" is Jan 1, 1970. System times represent seconds since then.
The first paper on Unix was published in 1974; the first widely distributed version, Version 7, appeared in 1979. Around the same time the University of California at Berkeley began work on various ports and variations of Unix; these ultimately became BSD Unix.
From early on, Unix supported pipes: the output of one program could be directly connected as the input of another:
ls -l | grep '^d'
This led to the Unix Philosophy: programs (at least "utility" programs) should be small, modular, general-purpose, and easily composable. Here is the version as set down by Doug McIlroy in 1978:
Point 3 is reminiscent of Eric Raymond's 1997 "bazaar" model of Linux development.
File redirection also was supported: the user could ask that input and output for a program come from files rather than the terminal.
One of the most important elements of the Unix design philosophy was that "everything is a file". That is, the printer appears to the system as a special file, and to print something, you write to it. Network sockets are special files you can read from and write to. Programs can communicate with one another through pipes. Here is a table of the Linux x64 system call interrupt numbers: https://filippo.io/linux-syscall-table. (User programs communicate with the kernel by executing an "interrupt" instruction after leaving the system call interrupt number in a register.) Note that the first three are
0 read()
1 write()
2 open()
Note also that there are now 457 entries, which means things have gotten Complicated in recent years.
Basically you have four options:
Running on a CS-department VM:
Homework 1: log into your CS-dept VM this way. The file hello.text contains a Magic Number. Email it to me.
Creating your own VM:
Github codespace:
(Don't try this with, say, Firefox with a heavily locked-down installation of NoScript.)
Windows/Mac shells:
If you have a Mac and open a Terminal, the shell zsh is run. It's close to bash.
If you have a Windows machine, you can install the Windows Subsystem for Linux, or WSL. Then, as I understand it, the common Linux commands are available through powershell (but probably not cmd). But there is still that issue of '/' versus '\' for file names.
The first shell was sh, the Bourne shell. While bash (the Bourne Again shell) is today more popular (by a lot), it's still very sh-like. There's also zsh. I have no idea what is going on with zsh; its ties to csh suggest weirdness.
Some things to try:
1. Type ls to list your files (there may not be any). It's short for "list". Why is it ls and not "lis" or "list"? I dunno, bytes were more expensive back then.
2. Type pwd to print your current directory.
3. Type cd to change to a different directory, eg cd / to change to the root (/) directory
Every process always has a "current working directory" (although the cwd can be deleted after the process starts).
The directory name following cd can be an absolute path, beginning with /, or a relative path, beginning with anything else.
4. Type ls -l to get a "long" list of files, with sizes. (In the / directory, there should be plenty.) What do all the columns mean?
5. Other options include aAbBcCdDfFgGhHiIklLmnNopqQrRsStTuUvwxXZ. Also some string-only options, like --full-time and --file-type and --dereference-command-line-symlink-to-dir. Welcome to my world!
6. Maybe you have a lot of files, and only want to look at the first few. Then ls -l | head will give you the first ten. The vertical bar is the pipe symbol. The output of ls -l is one line per file, and it becomes the input (via the pipe) to the head command, which prints the first 10 lines of its input and discards the rest. (You can print the first, say, 30 lines with head -n 30). If you want the ten most recent files, have ls print recent files first with the -t option: ls -lt | head.
7. ls dirname lists the files in the directory dirname (or if dirname is a regular file, it lists that file).
8. Options to ls that are more important: -l, -a, -t
9. Try ls --help. Or man ls
10. Plain ls does not show filenames beginning with ".". Use -a to show these hidden things Every directory contains two special entries, "." which refers to itself, and "..", which refers to the parent directory.
How does ls compare with a visual file browser? With ls, it's easy to get confused whether you just listed the files at the current directory, or in a subdirectory. At some point, though, the real issue is that text-based commands can be connected into pipes, and into scripts.
Shell stuff
We can type anything into the shell, even gibberish. (What happens when we do?)
Typing an up-arrow lets us see the previous command. Typing left-arrow and right-arrow let us move around a previous command, and edit it.
More basic commands
cat
cal (also cal 5 2024, but cal 5 24 is a looong time ago!) (Be sure to try cal 9 1752)
date
df
free