February 15, 2006

Coverage: [USP] Chapter 6, [UPE] Chapter 2

Hint on Opening Files

open(path, O_WRONLY | O_CREAT | O_TRUNC, mode) = creat(const char *path, mode_t mode) because former is so common

`s' Family of `printf`/`scanf` Functions

sprintf
snprintf
sscanf

Note about Pipes

writes to pipes are atomic (contrast with fprintf)
reads from pipes are not atomic

Interesting Notes about the Client-Server Programs

first version
- simple-request: a one-way communication protocol
  - clients send information to server
- why does server open pipe for writing, even though it will never write to it?
- client cannot cause server to terminate
second version
- request-reply: a two-way communication protocol
  - request pipe: client sends a request (`g')
  - sequence pipe: server sends a reply (sequence `#')
  - difficult to implement with only one named pipe
- server replies (i.e., the sequence #) can be read by any client because of the single, shared pipe
  - side-effect of non-atomic reads
- possible erroneous outcomes
  - partial input (e.g., read only 2 bytes)
  - complete, but incorrect, input due to the interleaving
- quick fix: have client who read partial input send an error code (`e') to the server on the request pipe to cause it to terminate
  - causes all future clients to block
  - causes all pending clients to terminate (writing to an unopened pipe)
- secure?
  - absolutely not
    - a malicious client could intentionally bring down the server
    - moral of the story: a client should never have the capability to shut down the server
- better solution
  - each client communicates to the server through its own individual named pipe

Experimental Runs of Client-Server Programs

one server, several clients (version one; exercise 6.12)
one server, two clients (version two; exercise 6.13)
two servers, one client (version two; exercise 6.14)
- it is possible that the client will get the same sequence # twice

Job Control

concurrent execution
- commands which allow control over multiple processes which are executing concurrently
- foreground: the current process which is attached to the user's terminal
- background: processes executing without being attached to a terminal (batch commands)
- command &: any shell command can be followed by an & (before the return) to run the command in the background

jobs

commands executed under the Korn shell are given a job number
$ jobs: command which lists the current jobs

[1]  + Stopped             spell termpaper
[2]  - Running             find /usr -name main.exe -print &

management

$ fg %<number>: moves a background job to the foreground
$ <ctrl-z>: suspends the current job and moves it to the background
$ bg %<number>: resumes execution of a job in the background.

$ ps: lists the running processes

  PID TT STAT   TIME COMMAND
12360 p0 S      0:01 -ksh (ksh)
12372 p0 I      0:00 main
12425 p0 R      0:00 ps -x

$ kill -STOP %<number>: suspends a running background job
$ kill %<number>: terminates the process with the corresponding job number
$ kill [-signum] <PID>: terminates the process with the corresponding process id
- can pass kill a signal #
  - -15 (default)
  - -2 (intr; same as <ctrl-c>)
  - -9 (sure kill; process cannot inoculate itself against this signal)
  - -3 (quit; same as <ctrl-\>)

some of these commands are built in to the shell and others are naive UNIX commands
- how to tell the difference?
  - do a man, if the BUILTIN(1) page is returned, the command is particular to the shell
    - e.g., $ man fg
    - print is a command available through the Korn shell

`stty` Command

get/set kernel metacharacters
remember that a command does not get its arguments until shell has interpreted all shell metacharacters
analogously, shell does not get command line until kernel has interpreted all kernel metacharacters
these settings control standard input from and output to the terminal, not the shell
how to redefine erase to # ?
- be careful
- stty erase \#
- why must we protect the hash?
stty sane
access/modification of terminal attributes through C
- tcgetattr and tcsetattr functions
- struct terminos

Character and Block Special Files in UNIX

files which represent hardware devices are located in /dev

character special file

$ ls -l /devices/pci@1e,600000/ide@d/dad@0,0:a,raw
crw-r-----   1 root     sys      136,  8 Feb 19 17:47 /devices/pci@1e,600000/ide@d/dad@0,0:a,raw

block special file

$ ls -l /devices/pci@1e,600000/ide@d/dad@0,0:a
brw-r-----   1 root     sys      136,  8 Feb 19 02:33 /devices/pci@1e,600000/ide@d/dad@0,0:a

read and write devices just as we do files
for more info, see chapter 7: `Device and Network Interfaces' of the UNIX manual
- $ man -s 7 intro

`crypt` Program

encrypts data
reads from standard input and writes to standard output
requires a key
your password is encrypted in the password file
- encryption algorithm has the property that it is easy to go from the unencrypted to the encrypted form, but very hard to go in the other direction

Terminals

tty0, tty1, ..., ptty00
- user terminals
- owned by user
- names vary
tty
- synonym for your login terminal
- terminal associated with this process
- sometimes referred to as controlling terminal
- fixed name
- ```
$ date >/dev/tty
Sun Feb 19 18:07:16 EST 2006
```
controlling terminals cannot be redirected from the command line
- consider users storing passwords in a file!

how to find out which terminal you are using

$ tty
/dev/pts/2
$ ls -l /dev/pts/2
lrwxrwxrwx   1 root     root          28 Aug  1  2005 /dev/pts/2 -> ../../devices/pseudo/pts@0:2
$
$ ls -l /devices/pseudo/pts@0:2
crw--w----   1 cps445-n1.03 tty       24,  2 Feb 19 18:02 /devices/pseudo/pts@0:2

notice that cps445-n1.03 owns it and has read and write permission on it
notice that those in the tty group (i.e., everybody) can write to it
chmod 600 /devices/pseudo/pts@0:2
- same as mesg n

use /dev/tty when program needs to interact with a user even when standard input and output are redirected

Echo Off

notice that in addition to explicitly reading from /dev/tty, crypt also turns off automatic character echoing
illustrated and experimented with code to turn echo off
- necessary for all sorts of authentication services

In-class Experimentation

getting write to work right :-)
what about talk ?
- the precursor to instant messaging

References

The UNIX Programming Environment

The C Programming Language

UNIX Systems Programming: Concurrency, Communication, and Threads