UNIX-Systemprogrammierung

1
UNIX-Systemprogrammierung
UNIX-Systemprogrammierung
Inhalt
© 1996, Axel T. Schreiner, Fachbereich Mathematik-Informatik, Universität Osnabrück
Eine Einführung in die Benutzung von UNIX (Dateien, Prozesse, Kommunikation) auf
der Ebene von Programmiersprachen wie C und Objective C.
Dieser Band enthält Kopien der OH-Folien, die in der Vorlesung verwendet wurden.
Diese Information steht außerdem im W orld-Wide Web online zur Verfügung; sie ist in
sich und mit einer Kopie der relevanten Manualseiten für Linux über Hypertext-Links
verbunden. Die Beispielprogramme werden maschinell in diesen Text eingefügt.
Gründliche Kenntnis von ANSI-C und Grundkenntnisse im Bereich objekt-orientierte
Programmierung werden vorausgesetzt. Der Band stellt kein komplettes Manuskript
der Vorlesung dar. Zum Selbststudium müßten zusätzlich Bücher über das UNIX-
System und auch über C-Programmierung konsultiert werden.
Einführung
Kopierprogramme
Systemaufrufe testen
Dateinamen
Implementierung der Datei-Klassen
Prozesse
Prozeßkommunikation

2
Kalender
April 16 Übersicht, Server, Programmieren mit Systemaufrufen, W as ist ein
Systemaufruf?
18 Programmieren mit Klassen, Fehlerbehandlung
23 Fehlerbehandlung, Main-Framework
25 Architektur der makefiles, Main-Framework
30 Main-Framework, Einfache Transfer-Operationen
Mai 2 Einfache Transfer-Operationen, Fd, ReadFd, WriteFd, PrintFd
7 Einfache Transfer-Operationen, Dateien kopieren, Dateien im
Adreßraum
9 krank
14 Dateien kopieren, Implementierung: Stat, Fd, ReadFd, WriteFd,
PrintFd, Path
16 Himmelfahrt
21 MappedReadFd, MappedWriteFd, Systemaufrufe testen
23 ls
28 Pfingsten
30 Pfingsten
Juni 4 Prozesse: Begriff, ps, proc-Dateisystem, Prozeßzustand
6 Prozeßmanipulationen: psj, Prozeßgruppen, Sessions, Terminalgruppen
11 Prozeßmanipulationen: Job-Control, Dämonen, Waisen. Signale
13 Posix-Probleme. orphan. Signale: Signal-Operationen, Signal-Nummern
18 Signale: Signal-Nummern, sig, dsh
20 Demo-Shell: Ziel, Architektur der Hauptschleife, fork, exec, wait
25
27
Juli 2
4
9 wird verlegt: 30.4. und 7.5. um 9:15 Uhr
11 wird verlegt: 14.5. und 21.5. um 9:15 Uhr

3
Termine
Vorlesung Dienstag, 10:15 31/449a Schreiner
Donnerstag, 16:15 31/449a
Übungen Montag, 12:15 31/449a Bischof
Sprechstunde Donnerstag ab 15:00 n.V. 31/321 Schreiner (969-2480)
31/318b Bischof (969-2534)
Literatur
Diese Folien befinden sich auf unserem WWW -Server
http://www.informatik.uni-osnabrueck.de/Vorlesung/USP und gedruckt in der
Lehrsammlung. Sie sollten mit einem W eb-Browser betrachtet werden. Bitte nicht per
Laserdrucker drucken. Hier können das jeweils aktuelle Skript (Mai/8) im HTML-
Format und die aktuellen Quellen als komprimierte TAR-Datei abgeholt werden.
Es gibt heute sehr viele Bücher über UNIX und Systemprogrammierung. Die
folgenden Bücher sind nützlich. Soweit vorhanden, befinden sie sich in der
Lehrsammlung.
Kernighan/Pike 3-446-14273-8 Der UNIX-Werkzeugkasten
Kerninghan/Ritchie 3-446-15497-3 Programmieren in C
NeXT Software 0-201-63251-9 NeXTSTEP Object-Oriented Programming and the
Objective C Language
Rochkind 0-13-011800-1 Advanced UNIX Programming
Stevens 0-201-56317-7 Advanced Programming in the UNIX Environment
Stevens 0-13-949876-1 UNIX Network Programming
Einige meiner Beispiele habe ich in Artikeln in unix/mail behandelt.
Einige Manual-Seiten für Linux befinden sich auch auf dem Server. Eine
private Kopie der Datei bookmarks.html eignet sich als Bookmarks für OmniWeb zum
schnellen Zugriff auf die Systemaufrufe. Bitte nicht per Laserdrucker drucken.

Einführung
Einführung
Dieser Abschnitt zeigt primitive Beispiele zur Programmierung mit Systemaufrufen und
mit Klassen und führt grundsätzlich verwendete Klassen ein.
Fd verkapselt einen File-Deskriptor, der die Verbindung zwischen einem Prozeß und
einer Datei repräsentiert. Diese Klasse wird erst im nächsten Abschnitt diskutiert.
Exception und Handler verkapseln die Behandlung von Fehlern in verschachtelten
Funktionsaufrufen.
Main ist ein Framework für ein Programm, das eine Kommandozeile bearbeitet.
Themen
Systemaufrufe
Programmieren mit Systemaufrufen
Was ist ein Systemaufruf?
Programmieren mit Klassen
Fehlerbehandlung
Ein Framework für die Kommandozeile
exit, _exit
write
Wichtige Bibliotheksfunktionen
perror
setjmp, longjmp
strerror
1-1

Programmieren mit Systemaufrufen
Programmieren mit Systemaufrufen — hello/hello.c
libc.h
hello gibt die Argumente aus, mit denen das Kommando aufgerufen wird.
hello illustriert ein typisches C-Programm, den Zugriff auf die Kommandozeile, die
Systemaufrufe write() und _exit() und die Bibliotheksfunktion perror() zur
Berichterstattung über Fehler bei Systemaufrufen.
#include "libc.h"
int main (int argc, char * argv []) {
const char * progname = argv[0];
}
while (* ++ argv) {
size_t len = strlen(argv[0]);
if (write(1, argv[0], len) != len
|| write(1, argv[1] ? " " : "\n", 1) != 1)
perror(progname), _exit(1);
}
return 0;
C-Funktionen sollte man vor Aufruf deklarieren.
unistd.h ist eine POSIX-Definitionsdatei für die Systemaufrufe. POSIX verträgt sich
(derzeit) nicht mit den präcompilierten Definitionsdateien für NeXT Objectvie C.
libc.h enthält (bei NeXTSTEP) Deklarationen der (meisten) Systemaufrufe. Wir
portieren, indem wir libc.h bei anderen Plattformen aus vorhandenen Definitionsdateien
zusammenstellen.
Kommandozeile
Die Ausführung eines C-Programms beginnt durch (impliziten) Aufruf von main(). Als
Argumente werden die ‘‘Wörter’’ der Kommandozeile übergeben.
$ hello hello, world
argv[]
null
h
h
w
e
e
o
l
l
r
l
l
l
o
o
d
\0
,
\0
main() erhält als int argc die Anzahl der Wörter auf der Kommandozeile und als char
\0
1-2

* argv[] die Wörter selbst. argc ist mindestens 1, denn der Kommandoname ist ein
Wort, und argv[argc] ist immer ein Nullzeiger.
File-Deskriptoren und Standard-Verbindungen
File-Deskriptoren sind kleine, nicht-negative, ganze Zahlen, die Dateiverbindungen für
Systemaufrufe repräsentieren.
Ein Prozeß hat normalerweise a priori drei Dateiverbindungen:
0 ist die Standard-Eingabe.
1 ist die Standard-Ausgabe.
2 ist die Diagnose-Ausgabe.
Ausgabe — write
size_t write (int fd, const char * buf, size_t count);
write() gibt bis zu count Bytes zur Dateiverbindung fd aus, beginnend mit dem Byte
bei buf, und liefert die Anzahl der ausgegebenen Bytes oder -1. Normalerweise ist das
Resultat count.
Fehlermeldungen — perror
void perror (const char * prefix);
perror() beschreibt den letzten Fehler, der von einem Systemaufruf verursacht wurde,
auf der Diagnose-Ausgabe. Davor wird prefix ausgegeben.
extern int errno;
char * strerror (int errno);
errno enthält eine Fehlernummer, die von Systemaufrufen nur gesetzt aber nicht
gelöscht wird. strerror() liefert die zugehörige Fehlermeldung, die perror() implizit
ausgibt.
Prozeßende — _exit
void _exit (int status);
void exit (int status);
int atexit (void (* function) (void));
_exit() beendet den Prozeß, ohne die Aufräumungsaufarbeiten, die exit() zusätzlich
vornimmt. status ist der Exit-Code des Prozesses, der dann an den erzeugenden
Prozeß geliefert wird.
atexit() hinterlegt Funktionen, die in umgekehrter Reihenfolge im Zuge von exit()
ausgeführt werden, und liefert 0 bei Erfolg oder -1 bei Fehler.
In main() ist return äquivalent zu exit(); der Resultatwert wird zum Exit-Code.
1-3

Was ist ein Systemaufruf?
Was ist ein Systemaufruf?
Systemaufrufe werden wie Bibliotheksfunktionen aufgerufen — in einem C-Programm
kann man keinen Unterschied erkennen.
Die Leistung eines Systemaufrufs wird jedoch im Kern des Betriebssystems, außerhalb
des Adreßraums des aufrufenden Prozesses erbracht:
0
1
.
.
.
Memory
Map
end
0
1
.
.
.
end
traps:
0 _exit
1 read
2 write
write:
...
main()
printf()
write()
trap 2
Kern
Hauptspeicher
Programm
Bibliotheken
Im Adreßraum des aufrufenden Prozesses befindet sich im Code der Funktion zum
Systemaufruf ein Maschinenbefehl zum Überwechseln in den Adreßraum des Kerns,
wobei eine Tabelle am Ziel für begrenzte Einsprungmöglichkeiten sorgt.
Der Kern hat wesentlich mehr Privilegien als der Benutzerprozeß — Hardware-Zugriff
auf Geräte, Definition der Memory Map, Kontrolle der Unterbrechbarkeit etc.
Aus der Sicht des Kerns sind Prozesse durch Tabelleneinträge beschrieben; der Kern
entscheidet, welchen Prozeß er zur Ausführung bringt.
1-4

File-Deskriptoren
Prinzipiell können bei Systemaufrufen zwischen Prozeß und Kern beliebige Daten
ausgetauscht werden. In der Praxis beschränkt man sich im Design auf einfache
Datentypen, die leicht zwischen den Adreßräumen transportiert werden können: int
oder Zeigerwerte in Registern sowie Puffer , die kopiert werden müssen.
Systemaufrufe haben fast immer int als Resultattyp, wobei -1 einen Fehler und Null
und manchmal positive Werte Erfolg anzeigen.
Dateiverbindungen werden durch File-Deskriptoren repräsentiert, die im Kern per
Prozeß als Indizes in eine Tabelle verwendet werden, die die Verbindungen beschreibt.
Dadurch kann der Kern Dateiverbindungen selbst dann korrekt terminieren, wenn der
Prozeß seinen eigenen Adreßraum total zerstört.
1-5

Programmieren mit Klassen
Programmieren mit Klassen — hello/echo.m
echo gibt die Argumente aus, mit denen das Kommando aufgerufen wird.
echo illustriert das Framework Main zur Bearbeitung der Kommandozeile und
Methoden der Klasse PrintFd zur Verkapselung von formatierter Ausgabe.
#include "Fd.h"
#include "Main.h"
@interface Echo: Object
{
id fout; // standard output
}
@end
@implementation Echo
- arg:(const char *)arg { // process one argument
if (! fout)
fout = [mainFrame fout];
else
[fout putc:’ ’];
[fout puts:arg];
return self;
}
- done { // following all arguments
if (fout)
[fout putc:’\n’];
return self;
}
@end
int main (int argc, char * argv []) {
[[[Main new] setClient:[Echo new]] run:argv];
return 0;
}
Objekt, Nachricht, Methode und Klasse
Ein Objekt verwaltet einen gewissen Zustand. Ein Programm besteht darin, daß
Objekte erzeugt werden, die dann miteinander kommunizieren und Aufgaben lösen.
main() hat bestenfalls die Aufgabe, Nachrichten an die zuständigen Objekte zu
vermitteln – die eigentlichen Aktivitäten wählt es selbst nicht aus.
Ein Objekt modelliert man natürlich mit einer Struktur , in der der Zustand gespeichert
wird. Eine Nachricht ist dann ein Funktionsaufruf, der sich auf ein Objekt bezieht und
dessen Zustand ändert. Die Funktion selbst nennt man eine Methode .
Eine Klasse besteht aus Objekten, die die gleichen Nachrichten empfangen können
und damit gleichartige Zustände (Strukturen) und Methoden (Funktionen) besitzen.
Dynamische Bindung
Die gleiche Nachricht kann durchaus für völlig verschiedene Objekte sinnvoll sein:
1-6

initialize, draw, free usw.
Der gleiche Funktionsname kann also auf verschiedene Klassen von Objekten
angewendet werden — was die Funktion exakt tut, kann von der Klasse des Objekts
abhängen. Wenn beim Übersetzen die genaue Klasse des Objekts noch nicht bekannt
ist, wird die Funktion endgültig erst zur Laufzeit ausgewählt — man spricht von
dynamischer Bindung.
Unabhängig von der Klasse müssen Argumente und Resultattyp allerdings schon beim
Übersetzen bekannt sein.
Information Hiding
Um Chaos zu vermeiden, sollte der Zustand eines Objekts möglichst gut verkapselt
sein. Nur Methoden dürfen den Zustand ändern.
Für eine Klasse definiert man daher eine Struktur und Funktionen, wobei nur die
Funktionen Zugriff auf die Strukturkomponenten besitzen.
Objective C
Objective C ist ANSI C mit wenigen Erweiterungen zur objekt-orientierten
Programmierung. Die Sprache wurde von Cox definiert. Es gibt Implementierungen von
Cox’ Firma Stepstone, von NeXT und von GNU. Entscheidend ist, daß man nicht nur
einen Compiler, sondern auch die Klasse Object benötigt — nur die Systeme von NeXT
und GNU sind deshalb einigermaßen kompatibel miteinander.
Im wesentlichen gibt es zwei Erweiterungen: man kann Klassen (Struktur und
Funktionen) vereinbaren und Nachrichten an Objekte versenden (Funktionen für
Objekte aufrufen).
Nachrichten
Ein Objekt ist eigentlich ein Zeiger, der aber normalerweise mit dem Typ id vereinbart
wird. Eine Nachricht ist ein Funktionsaufruf mit einer speziellen Syntax und mit einem
Objekt als erstem Argument — das Objekt ist der Empfänger der Nachricht, und die
Funktion nennt man Methode. Innerhalb der Methode heißt der Empfänger self.
#include Definitionsdatei, einmal eingefügt
id anObject; vereinbaren
anObject = [Object new]; erzeugen
if ([anObject isMemberOf:[Object class]]) prüfen
[anObject free]; zerstören
Die Syntax einer Nachricht ist an SmallTalk angelehnt:
[empfänger name] ohne Argumente
[empfänger name:argument key:argument ...] mit Argumenten
[empfänger name:argument, argument ...] mit variablen Argumenten
Der Name der Methode ist die Folge name:key:.. und muß im System eindeutig sein.
Eine Methode kann für verschiedene Klassen definiert sein.
1-7

Klassen und Klassenmethoden
Es gibt eine Reihe von vordefinierten Klassen, die eine Hierarchie bilden, die mit der
Klasse Object beginnt. Für jede Klasse gibt es ein Klassenobjekt, von dem man mit
Hilfe der Methode new ein neues Objekt erhält.
Es gibt ein Objekt nil und eine Klasse Nil; beides sind Null-Zeiger. nil akzeptiert jede
Nachricht und liefert immer Null als Resultat.
new ist eine Klassenmethode, denn damit wird eine Nachricht an ein Klassenobjekt
geschickt. Es ist nur eine Abkürzung für:
id anObject = [[Object alloc] init];
[anObject free];
alloc ist eine Klassenmethode, die ein Objekt erzeugt und mit 0 initialisiert; init ist
eine Methode, die das resultierende Objekt initialisiert. Eine Variante von init muß
unbedingt aufgerufen werden.
free ist eine Methode, die den Speicherbereich ihres Empfängers freigibt. free liefert
normalerweise nil als Resultat.
class ist eine Methode und eine Klassenmethode, die jeweils einen V erweis auf das
Klassenobjekt liefert:
if ([anObject class] == [Object class])
puts("super");
Der Name einer Klasse wird nur als Empfänger direkt angegeben – sonst muß man
class verwenden, um vom Klassennamen zum Klassenobjekt zu kommen.
Klassenmethoden und Methoden können die gleichen Namen besitzen.
1-8

Fehlerbehandlung
Fehlerbehandlung
Prinzip
Fehler passieren meistens in verschachtelten Funktionsaufrufen und sollen dann auf
einer äußerem Ebene abgefangen werden. Manche Sprachen bieten folgende
Kontrollstruktur, die verschachtelt werden kann:
try {
} catch {
}
falls hier irgendwo ein Fehler passiert...
[Exception throw:..]
Fehlerbehandlung
Globaler Transfer — setjmp
Zu einem ANSI-C System gehören die Funktionen setjmp() und longjmp(), die
folgende Konstruktion ermöglichen:
jmp_buf on_error;
if (setjmp(on_error)) {
} else {
}
Fehlerbehandlung
falls hier irgendwo ein Fehler passiert...
longjmp(on_error, ...);
int setjmp(jmp_buf jb);
setjmp() definiert jb als Ziel eines späteren longjmp() und liefert zunächst Null.
void longjmp(jmp_buf jb, int value);
longjmp() sorgt dafür, daß der letzte Aufruf von setjmp(), der jb gesetzt hat, nochmals
ein Resultat liefert — entweder value, falls von Null verschieden, oder 1. Der
Funktionsaufruf, zu dessen setjmp() zurückgesprungen wird, muß noch aktiv sein.
Das Problem besteht darin, setjmp() und longjmp() so systematisch zu verwenden,
daß auch Fehlerbehandlung verschachtelt werden kann — man braucht einen Stack
von jmp_buf-Werten.
1-9

Ein triviales Beispiel — try/try.m
try gibt einen Text aus.
try illustriert die Klassen Handler und Exception, mit denen man sich systematisch bei
Fehlern aus verschachtelten Funktionsaufrufen befreien kann.
#include
#include "Exception.h"
int main () {
id h = [Handler new];
}
if (catch(h))
puts([[h exception] info]);
else
[Exception throw:"something funny"];
[h free];
return 0;
Mit den Klassen kann man Folgendes machen:
id h = [Handler new];
if (catch(h)) {
} else {
}
Fehlerbehandlung
[[h exception] info];
falls hier irgendwo ein Fehler passiert...
[h free];
[Exception throw: ...];
Handler-Objekte müssen exakt verschachtelt erzeugt und freigegeben werden.
catch() beruht auf setjmp() und bereitet einen Handler zum Fehlerempfang vor, wobei
das Resultat 0 geliefert wird. catch() ist ein Makro (warum?!).
Eine Fehlerbehandlung wird mit throw: ausgelöst, wobei ein Text im Stil von printf()
erzeugt wird, der später mit info abgefragt werden kann. Unterklassen von Exception
mit mehr Information sind möglich.
Für den neuesten, vorbereiteten Handler liefert catch() dann 1. exception liefert dann
das durch throw: erzeugte Exception-Objekt.
Der Handler verwaltet jeweils das Exception-Objekt. Es wird implizit freigegeben,
wenn der Handler freigegeben wird.
1-10

Ein komplizierteres Beispiel — try/errno.m
errno gibt die Werte 1 bis 3 aus und bricht dann wegen einer Exception ab.
errno illustriert verschachtelte Handler und eine Unterklasse von Exception.
#include
#include
#include "Exception.h"
@interface Errno: Exception
{
int errno; // info as a number
}
- (int)errno;
@end
@implementation Errno
- init:(int)e info:(const char *)fmt :(va_list)ap {
[super init:e info:fmt :ap];
errno=atoi(info); // a bit of a kludge...
return self;
}
- (int)errno {
return errno;
}
@end
void main () {
id a = [Handler new], b = [Handler new];
}
switch (catch(a), [[a exception] errno]) {
case 0: switch (catch(b), [[b exception] errno]) {
case 0: [Errno throw:"1"]; assert(0);
case 1: puts("caused 1"); // 1
[Errno throw:"2"]; assert(0);
case 2: puts("caused 2"); // 2
[b free]; [Errno throw:"3"];
}
assert(0);
case 3: puts("caused 3"); // 3
[a free]; [Errno throw:"4"];
}
assert(0);
1-11

Interface — Exception.h
#ifndef Exception_h
#define Exception_h
#include
#include
#include
// handler = [Handler new];
// if (catch(handler)) { [handler exception] }
// else { [Exception throw:...] }
// [handler free];
@interface Handler: Object // stack of Exception handlers
{ // new/free properly nested
jmp_buf label; // for setjmp/longjmp
BOOL armed; // set once label is set
id exception; // current problem if any
}
- (void *)_setjmp; // only for catch()
- disarm; // opens a window outward
- exception;
- (void)rethrow; // current exception -> outer handler
@end
#define catch(handler) setjmp([handler _setjmp])
@interface Exception: Object // sent from throw to catch’s handler
{ // recycled by handler
char * info; // information about a problem
}
+ new:(const char *)fmt, ...; // [[self alloc] init...]
+ new:(const char *)fmt :(va_list)ap;
+ new:(int)e info:(const char *)fmt, ...;
+ new:(int)e info:(const char *)fmt :(va_list)ap;
+ throw; // [[self new...] throw]
+ throw:(const char *)fmt, ...;
+ throw:(const char *)fmt :(va_list)ap;
+ throw:(int)e info:(const char *)fmt, ...;
+ throw:(int)e info:(const char *)fmt :(va_list)ap;
- init; // init:errno info:0
- init:(const char *)fmt, ...; // init:0 info:fmt :...
- init:(const char *)fmt :(va_list)ap; // init:0 info:fmt :ap
- init:(int)e info:(const char *)fmt, ...; // info = [fmt...][:strerror(e)]
- init:(int)e info:(const char *)fmt :(va_list)ap; // designated init’er
- (const char *)info;
- throw; // send to top catch()
@end
#endif
Die Notwendigkeit von armed, disarm und rethrow erkennt man erst während der
Implementierung. Mit new kann man eine Exception erzeugen, die erst später mit throw
ausgelöst wird.
Da catch() ein Makro sein muß, benötigt man _setjmp. Falls etwa ein jmp_buf nicht als
void* übergeben werden könnte, schaltet man noch eine Struktur dazwischen.
Für Funktionen mit variablen Argumentlisten sollte man immer auch die Versionen
implementieren, die Zeiger akzeptieren.
1-12

Implementierung — Handler
@implementation Handler
+ initialize {
if (self == [Handler class])
stack = [List new];
return self;
}
- init { // push new Handler
[stack addObject:[super init]];
return self;
}
- free { // pop up to current Handler
id last; // but do not free intervening ones
do
if (! (last = [stack removeLastObject]))
[self error:"exception handler stack underflow\n"];
while (last != self);
[exception free]; // free our exception, if any
return [super free];
}
- (void *)_setjmp {
armed = YES; // protects uninit’ed jmp_buf
return label;
}
- disarm {
armed = NO;
return self;
}
- exception {
return exception;
}
- (void)rethrow {
id current = exception;
exception = nil, [self free];
[Handler _throw:current];
}
@end
Handler verwendet einen globalen Stack aller seiner (aktiven) Objekte, der in
initialize einmal angelegt wird.
init notiert neue Handler auf dem Stack, free entfernt auch die offenbar vergessenen.
Die letzte Exception löscht free.
_setjmp verwaltet die Bedingung armed, da man einem jmp_buf nicht ansieht, ob er
gesetzt wurde.
Eine versteckte Klassenmethode _throw: dient dazu, ein Exception-Objekt an den
innersten, aktivierten Handler zu liefern. Eine ältere Exception wird dabei freigegeben:
1-13

#include
#include
#include
#include "Exception.h"
#ifndef MAXINFO
#define MAXINFO 1024 // max length of Exception info
#endif
static id stack; // List of nested handlers
@interface Handler (private)
+ (void)_throw:exception; // longjmp or crash...
@end
@implementation Handler (private)
+ (void)_throw:_exception {
unsigned n = [stack count];
while (n -- > 0) { // try stack...
Handler * handler = [stack objectAt:n];
1-14
if (handler->armed) {
[handler->exception free], handler->exception = _exception;
longjmp(handler->label, 1);
}
} // oops...
[[_exception class] error:"%s: uncaught exception\n", [_exception info]];
}
@end

Implementierung — Exception
new und throw führen im W esentlichen zur zentralen init-Methode und dann zu throw.
Hier sind Beispiele:
+ new:(int)e info:(const char *)fmt :(va_list)ap {
return [[self alloc] init:e info:fmt :ap];
}
+ throw:(int)e info:(const char *)fmt, ... {
va_list ap;
}
va_start(ap, fmt);
return [[self new:e info:fmt :ap] throw];
- init:(int)e info:(const char *)fmt :(va_list)ap {
char buf [MAXINFO] = "";
[super init];
if (fmt && fmt[0]) {
vsprintf(buf, fmt, ap);
if (e)
strcat(buf, ": ");
}
if (e)
strcat(buf, strerror(e));
if (! (info = malloc(strlen(buf)+1)))
[self error:"no more memory\n"];
strcpy(info, buf);
return self;
}
- free {
free(info);
return [super free];
}
- (const char *)info {
return info ? info : "";
}
- throw {
[Handler _throw:self];
return self; // dummy
}
@end
Exception verwaltet einen dynamischen String. throw schickt die Exception an den
innersten, vorbereiteten Handler.
1-15

Ein Framework für die Kommandozeile
Ein Framework für die Kommandozeile
Ein Framework ist eine Klasse, von der ein einziges Objekt existiert, das die
Hauptschleife eines Programms abwickelt. Ein Framework soll die Routineaufgaben
einer Klasse von Programmen abwickeln. Dazu können durchaus weitere Objekte
anderer Klassen verwendet werden.
In UNIX hat sich ein gewisser Standard für die Gestaltung von Kommandozeilen
eingebürgert:
Optionen gehen Argumenten voraus und beginnen mit einem Minuszeichen,
dem Flaggen folgen.
Flaggen sind einzelne Buchstaben, die beliebig in Optionen zusammengefaßt
werden können..
Zu einer Flagge kann ein Wert angegeben sein, der der Flagge als Rest der
Option oder als nächstes Argument folgt.
Ein einzelnes Minuszeichen beendet die Optionen und gilt als Argument —
normalerweise als Verweis auf die Standard-Eingabe.
Eine Option aus zwei Minuszeichen beendet die Optionen, gilt aber nicht als
Argument.
1-16

Das Framework Main
Da sich sehr viele Kommandos an diesen Standard halten, bietet sich an, dessen
Implementierung in einer Klasse Main zu verkapseln: Main erhält die Argumente von
einem Klienten-Objekt und schickt Nachrichten über decodierte Flaggen und
Argumente zurück an den Klienten, der deshalb das Protokoll CommandLine
implementieren muß:
CommandLine
setClient:
run:
flag:
nextarg
noarg arg:
arg nextarg
length
fd:
done
Initialisierung
Flaggen
Argumente
als Fd
Abschluß
mainFrame
Damit nicht alle Methoden aus diesem Protokoll explizit implementiert werden
müssen, gibt es eine Klasse MainClient, die CommandLine implementiert, und von der
ein Klient abgeleitet werden kann, der nur einige Methoden ersetzt.
MainClient
Klient
MainClient
Main
Damit der Klient weder von MainClient abstammen, noch CommandLine voll
implementieren muß, stammt Main selbst auch von MainClient ab und schickt die
Nachrichten an sich selbst, die der Klient nicht implementiert.
MainClient erlaubt keine Flaggen und interpretiert Argumente als Dateinamen, für die
File-Deskriptoren mit Lesezugriff erzeugt und mit fd: bearbeitet werden. Gibt es keine
Argumente, wird fd: mit der Standard-Eingabe aufgerufen. Dies ist für manche
Filterprogramme recht praktisch. fd: ist ohne Funktion.
1-17

Ein triviales Beispiel — main/cmd.m
cmd erlaubt die Flagge -f mit und -v ohne Optionswert. Argumente müssen lesbare
Dateien sein.
cmd illustriert eine Verwendung des Frameworks Main.
#include "Exception.h"
#include "Fd.h"
#include "Main.h"
@interface Cmd: MainClient
@end
@implementation Cmd
- flag:(char)ch {
switch (ch) {
case ’f’: [[mainFrame fout] puts:"-f\n"]; break;
case ’v’: [[mainFrame fout] printf:"-v %s\n", [mainFrame nextarg]];
break;
default: [super flag:ch];
}
return self;
}
@end
int main (int argc, char * argv []) {
id handler = [Handler new];
}
if (catch(handler)) {
id e = [handler exception];
[mainFrame error:"usage: %s file...", [mainFrame progname]];
[mainFrame fatal:"%s: %s", [[e class] name], [e info]];
}
[[[Main new] setClient:[Cmd new]] run:argv];
return 0;
Cmd ist der Klient, der nur die ihm bekannten Flaggen selbst abschöpft.
Main verursacht einige Fehler wie unkekannte Flaggen, unzugängliche Dateien etc.
Diese werden hier in einem Handler abgefangen, der auch eine Gebrauchsanweisung
ausgibt.
1-18

Interface — Main.h
#ifndef Main_h
#define Main_h
#include
#include
@protocol CommandLine
- flag:(char)ch; // -f
- noarg; // no arguments
- arg:(const char *)arg; // each argument
- fd:fd; // argument as fd
- done; // after all arguments
@end
@interface MainClient: Object
@end
extern id mainFrame; // the single object, returned by +new
@interface Main: MainClient
{
id flag, noarg, arg, fd, done; // message receivers
char ** argv; // argument list
const char * progname; // argv[0]
int pos; // next pos in *argv
id fin, fout, ferr; // stdin, stdout, stderr
}
- initMain:(const char *)progname; // sets progname, if any
- setClient:client; // sets receivers
- run:(char **)argv; // main loop, returns [done done]
- (const char *)progname; // argv[0]
- (const char *)arg; // current *argv
- (const char *)nextarg; // option’s (next) value, next *argv
- (int)length; // # arguments, with current
- fin; // stdin
- fout; // stdout
- ferr; // stderr
- error; // error message for errno
- error:(const char *)fmt, ...; // ... with formatted text
- error:(const char *)fmt :(va_list)ap;
- (void)fatal; // terminate for errno
- (void)fatal:(const char *)fmt, ...; // ... with formatted text
- (void)fatal:(const char *)fmt :(va_list)ap;
@end
#endif
progname, arg und nextarg greifen auf die Kommandozeile zu, length liefert die Zahl
der verbleibenden Argumente.
fin, fout und ferr liefern Fd-Objekte für die Standard-Verbindungen.
error: und fatal: standardisieren die Behandlung häufiger Probleme. Wahrscheinlich
braucht man auch eine Version, die direkt eine Exception akzeptiert.
1-19

Implementierung — MainClient
#include
#include
#include "Exception.h"
#include "Fd.h"
#include "Main.h"
id mainFrame;
@implementation MainClient
- flag:(char)ch { // don’t allow flags
return [Exception throw:"flag -%c not permitted", ch];
}
- noarg { // offer stdin
[mainFrame fd:[mainFrame fin]];
return self;
}
- arg:(const char *)arg { // offer arg or stdin for -
id f;
if (strcmp(arg, "-") == 0)
return [self noarg];
f = [ReadFd open:arg];
[mainFrame fd:f];
[f free];
return self;
}
- fd:fd { // dummy to handle Fd
return self;
}
- done { // dummy epilogue
return self;
}
@end
In MainClient werden Methoden hinterlegt, die dann zum Zug kommen, wenn sie der
Klient nicht selbst implementiert, oder wenn er sie zur Fehlerbehandlung nutzt.
Auch Fd verwendet natürlich Exception zur Fehlerbehandlung, deshalb müssen die
Nachrichten nicht geprüft werden.
1-20

Implementierung — Main
@implementation Main
+ new {
return mainFrame ? mainFrame : [[self alloc] init];
}
+ alloc { // don’t let another one be created
if (mainFrame)
[self error:"cannot create another object\n"];
return mainFrame = [super alloc];
}
- initMain:(const char *)_progname {
if (self != mainFrame) // don’t let another one be init’ed
[self error:"cannot create another object\n"];
[super init];
if (_progname && _progname[0])
progname = _progname;
return self;
}
- init {
return [self initMain:0];
}
- free { // don’t let it be freed
return nil;
}
- setClient:client {
#define receiver(msg) \
[client respondsTo: @selector(msg)] ? client : self
flag = receiver(flag:);
noarg = receiver(noarg);
arg = receiver(arg:);
fd = receiver(fd:);
done = receiver(done);
#undef receiver
return self;
}
- fd:_fd { // send to intended receiver
return fd == self ? self : [fd fd:_fd];
}
- done { // make sure, fout is complete
[fout close];
return self;
}
Es gibt nur ein einziges Main-Objekt, das überall als mainFrame oder mit new erreicht und
niemals freigegeben werden kann.
setClient: legt fest, wer die Nachrichten der CommandLine erhält.
fd: wird ersetzt, damit File-Deskriptoren von Main (alias MainClient) an den eigentlich
erwünschten Empfänger weitergeleitet werden.
done schließt fout, denn bei einer Netzverbindung könnte da noch ein Fehler auftreten.
Dies hätte vielleicht auch in MainClient geschehen sollen.
1-21

- run:(char **)_argv {
if (! (argv = _argv) || ! argv[0])
[Exception throw:"invalid argument vector"];
if (! progname || progname == argv[0]) // set/skip progname
progname = * argv ++;
}
while (argv[0] && argv[0][0] == ’-’) { // option loop
switch (argv[0][1]) {
case ’\0’: // - is a filename
break; // ... and ends options
case ’-’:
if (argv[0][2] == ’\0’) { // --
++ argv; // ... is ignored
break; // ... and ends options
}
default: // -abc -fvalue
for (pos = 2; argv[0][pos-1]; ++ pos)
[flag flag:argv[0][pos-1]];
++ argv; // next argument
continue;
}
break;
}
if (argv[0]) // argument loop
do
pos = strlen(argv[0]), // so that [arg] advances
[arg arg:argv[0]];
while (* ++ argv);
else // no arguments
[noarg noarg];
return [done done];
run: verwaltet die Hauptschleife mit den Invarianten argv (aktuelles Argument) und pos
(Position des nächsten Zeichens in argv[0]).
Der Code ist einfacher als in der konventionellen Lösung, erlaubt aber klarere
Rückfragen.
progname kann entweder hier oder schon in initMain: gesetzt werden — damit kann
auch ein Vektor von Strings als Kommandozeile verarbeitet werden.
1-22

- (const char *)progname {
if (! progname) {
static char buf [10];
sprintf(buf, "[%d]", (int)getpid());
progname = buf;
}
return progname;
}
- (const char *)arg {
if (! argv || ! argv[0])
[Exception throw:"missing argument"];
return argv[0];
}
- (const char *)nextarg {
const char * item = 0;
if (argv && argv[0])
item = argv[0][pos] ? &argv[0][pos] : * ++ argv;
if (item)
pos = strlen(argv[0]); // so that [arg] or [run:] advance
else
[Exception throw:"missing argument"];
return item;
}
- (int)length {
int result = 0;
if (argv)
while (argv[result])
++ result;
return result;
}
- fin {
return fin ? fin : (fin = [[ReadFd alloc] initFd:0]);
}
- fout {
return fout ? fout : (fout = [[PrintFd alloc] initFd:1]);
}
- ferr {
return ferr ? ferr : (ferr = [[PrintFd alloc] initFd:2]);
}
progname, arg und length betrachten die Kommandozeile.
nextarg greift in den Ablauf der Hauptschleife durch Änderung der Invarianten ein.
fin etc. liefern Fd-Objekte, die nur bei Bedarf einmal erzeugt werden.
1-23

- error {
return argv[0] && argv[0][0]
? [self error:"%s: %s: %s",
[self progname], argv[0], strerror(errno)]
: [self error:"%s: %s", [self progname], strerror(errno)];
}
- error:(const char *)fmt, ... {
va_list ap;
va_start(ap, fmt);
return [self error:fmt :ap];
}
- error:(const char *)fmt :(va_list)ap {
if (fmt)
[[self ferr] printf:fmt :ap], [[self ferr] putc:’\n’];
else
[self error:"%s: unknown error", [self progname]];
return self;
}
- (void)fatal {
[self error];
return [self fatal:""];
}
- (void)fatal:(const char *)fmt, ... {
va_list ap;
va_start(ap, fmt);
return [self fatal:fmt :ap];
}
- (void)fatal:(const char *)fmt :(va_list)ap {
[self error:fmt :ap];
exit(1);
}
@end
Mit derartigen Methoden kann man die Fehlerberichte zentralisieren und
standardisieren. Werden die Methoden in einer Unterklasse ersetzt, gewinnt man zum
Beispiel den Effekt von atexit() bei Abbruch.
Zum Gebrauch in Pipelines sollten die Berichte immer den Programmnamen enthalten.
1-24

1-25

Kopierprogramme
Kopierprogramme
Dieser Abschnitt beschäftigt sich anhand von cat und cp mit Klassen, die
Systemaufrufe zum Zugriff auf Dateien verkapseln.
Stat enthält Informationen über ein Objekt im Dateisystem (Inode), aus denen zum
Beispiel die eindeutige Identität, Zugriffsschutz, Größe und Art bestimmt werden
können. Die Information ist per Dateiname oder File-Deskriptor erreichbar, deshalb gibt
es zwei Unterklassen. Fehler werden als IOException gemeldet.
Fd verkapselt einen File-Deskriptor, der die Verbindung zwischen einem Prozeß und
einer Inode repräsentiert. Unterklassen erlauben nur die Operationen, die für den File-
Deskriptor möglich sind.
Path verkapselt einen Dateinamen und die Operationen, die damit vorgenommen
werden können.
Themen
Systemaufrufe
Einfache Transfer-Operationen
Klassen für Dateien
Dateien im Adreßraum
Dateien kopieren
chmod
close
creat
fcntl
fstat
lseek
lstat, stat
map_fd
mmap, munmap
open
read
unlink
write
2-1

Einfache Transfer-Operationen
Einfache Transfer-Operationen — cat
cat interpretiert seine Argumente als Dateinamen und kopiert die Inhalte zur Standard-
Ausgabe. Ohne Argumente oder für jedes Argument - wird von der Standard-Eingabe
kopiert.
cat illustriert Dateizugriff mit den Fd-Klassen und die Transfer-Operationen.
cat wird in vier Schritten verfeinert:
cat0 ist eine triviale Lösung.
cat1 versucht, eine Datei nicht in sich selbst zu kopieren.
cat2 läßt trotzdem Kopieren von und zu einem Gerät zu.
cat3 ist wesentlich effizienter , da eine Datei im Speicher abgebildet wird.
Hauptprogramm für cat
Das Hauptprogramm erzeugt ein Object als Klient von Main und erklärt Details einer
etwaigen Exception.
#include "Stat.h" // IOException
#include "Main.h"
int main (int argc, char * argv []) {
id handler = [Handler new];
}
if (catch(handler)) {
id e = [handler exception];
if (! [e isKindOf:[IOException class]])
[mainFrame error:"usage: %s file...", [mainFrame progname]];
[mainFrame fatal:"%s: %s", [[e class] name], [e info]];
}
[[[Main new] setClient:[Object new]] run:argv];
return 0;
2-2

cat0
Main liefert fertige ReadFd-Objekte an die zu Object als Kategorie hinzugefügte
Methode fd:
#include "Fd.h"
#include "Main.h"
@implementation Object (cat)
- fd:fd {
return [fd cat:[mainFrame fout]];
}
@end
Die trivialste Lösung stützt sich auf eine Methode cat: von ReadFd, die ihrerseits
transfer: verwendet:
- transfer:fout {
int n;
char buf [BUFSIZ];
}
while ((n = [self read:buf len:sizeof buf]))
if ([fout write:buf len:n] != n)
[IOException throw:errno info:"write \"%s\"", [fout name]];
return self;
Die Ausgabe muß zu einem WriteFd-Objekt erfolgen. Kopiert wird mit read:len: und
write:len: — bei Fehlern gibt es eine IOException und write:len: sollte immer die
richtige Länge ausgeben können.
Die IOException sollte zu einer anderen Fehlermeldung führen als die vom Framework
erzeugten Exception-Objekte.
2-3

cat1
cat1 versucht, eine Kopie zu vermeiden, falls Eingabe und Ausgabe zur gleichen Datei
führen.
#include "Fd.h"
#include "Main.h"
@implementation Object (cat)
- fd:fd {
id fout = [mainFrame fout];
if ([[fd fstat] isEqual:[fout fstat]])
[Exception throw:"\"%s\" equals \"%s\"", [fd name], [fout name]];
return [fd cat:fout];
}
@end
isEqual: ist eine Methode von Object, die Objekt-Äquivalenz implementieren soll. Für
File-Deskriptoren und Dateinamen muß das Problem auf die Gleichheit der dahinter
befindlichen Inodes zurückgeführt werden. Dazu dient die Klasse Stat:
- (BOOL)isEqual:obj {
if (obj == self)
return YES;
if ([obj isKindOf:[Stat class]])
{ Stat * sp = obj;
}
if (s.st_dev == sp->s.st_dev && s.st_ino == sp->s.st_ino)
return YES;
}
return NO;
Nur die Kombination aus Inode-Nummer st_ino und Gerätenummer st_dev ist
eindeutig — dies gilt auch für Dateien im NFS.
Bevor die Stat-Information für einen File-Deskriptor oder Dateinamen verwendet
werden kann, muß sie durch Methoden wie fstat erzeugt werden.
2-4

cat2
cat2 vermeidet das Problem, daß bei Geräten wie /dev/tty Eingabe und Ausgabe
durchaus gleichzeitig erfolgen können, indem der Test nur bei Dateien vorgenommen
wird:
#include "Fd.h"
#include "Main.h"
@implementation Object (cat)
- fd:fd {
id fout = [mainFrame fout];
if ([[fd fstat] isFile] && [fd isEqual:[fout fstat]])
[Exception throw:"\"%s\" equals \"%s\"", [fd name], [fout name]];
return [fd cat:fout];
}
@end
Ob eine Inode eine Datei beschreibt, kann wieder in Stat geklärt werden:
- (BOOL)isFile {
return (s.st_mode & S_IFMT) == S_IFREG;
}
Auch für isFile muß zuerst die Stat-Information zum Beispiel mit fstat aktualisiert
werden.
2-5

cat3
UNIX kann Programme zwischen Hauptspeicher und Platte verlagern, um den Speicher
besser zu nutzen (Swapping). In der Regel kann der konstante Programmtext aus der
Programmdatei gelesen werden und nur die Daten müssen voll verschoben werden.
Hauptspeicher
0
1
.
.
.
end
Text
Daten
Datei
Platte
Programm
Swap-Bereich
Datei
Daten
Die Zeichnung deutet an, daß diese ohnehin vorhandenen Mechanismen auch dazu
verwendet werden können, eine Datei im Adreßraum eines Prozesses abzubilden. Für
Lesezugriff leistet dies die Klasse MappedReadFd.
cat3 ist wesentlich effizienter für Dateien, die in den Hauptspeicher abgebildet werden
können.
#include "MappedFd.h"
#include "Main.h"
@implementation Object (cat)
- fd:fd {
id fout = [mainFrame fout];
if ([[fd fstat] isFile] && [fd isEqual:[fout fstat]])
[Exception throw:"\"%s\" equals \"%s\"", [fd name], [fout name]];
return [fd cat:fout];
}
- arg:(const char *)arg {
id f;
if (strcmp(arg, "-") == 0)
return [mainFrame noarg];
f = [MappedReadFd open:arg];
if ([f isMemberOf:[MappedReadFd class]])
[[mainFrame ferr] printf:"%s mapped\n", arg];
[self fd:f];
[f free];
return self;
}
@end
Eine Abbildung wird nur für Dateien vorgenommen, die nicht als Standard-Eingabe
2-6

verwendet werden. Die Standard-Eingabe kann mehrfach abgefragt werden; das ist nur
sinnvoll, wenn sie dazwischen wächst, was sich aber in der Abbildung nicht unbedingt
auswirkt.
Für Dateien liefert open: einen MappedReadFd, für andere Inodes wird stillschweigend
ein ReadFd geliefert.
- transfer:fout {
const void * buf;
size_t n, len;
}
for (n = 0; (buf = [self at:n len:&len]); n += len)
if ([fout write:buf len:len] != len)
[IOException throw:errno info:"write \"%s\" truncated",
[self name]];
return self;
MappedReadFd ersetzt transfer: und führt statt read:len: eine Abbildung mit at:len:
durch.
2-7

Klassen für Dateien
Klassen für Dateien
Stat
In diesem Abschnitt wird die Funktionalität der Klassen vorgestellt, die
Implementierungen folgen später .
Stat Stat.h Stat.m Information über ein Objekt im Dateisystem
Path Path.h Path.m Dateiname
Fd Fd.h Fd.m File-Deskriptor, Dateiverbindung
ReadFd Lesezugriff
MappedReadFd Abbildung zum Lesen
WriteFd Schreibzugriff
MappedWriteFd Abbildung zum Schreiben (und Lesen)
PrintFd PrintFd.m formatierte Ausgabe
Ein Stat-Objekt verkapselt die Information, die vom Betriebssystem über ein Objekt im
Dateisystem zu erfahren ist.
#ifndef Stat_h
#define Stat_h
#include // off_t
#include
#include "Exception.h"
@interface Stat: Object // base class for Fd and Path
{
struct stat s; // optional, describes attributes
}
- (BOOL)isEqual:obj; // TRUE if same inode on same device
- (BOOL)isFile; // true for regular file
- (BOOL)isDir; // true for directory
- (short)mode; // (current) mode
- (long)size; // (current) size
@end
@interface IOException: Exception
@end
#endif
Beim Umgang mit Stat-Objekten kann es zu einer IOException kommen.
Bevor die Information gültig ist, muß sie von einer Unterklasse aus aktualisiert werden.
2-8

Path
Ein Path-Objekt macht die Stat-Information mit Hilfe eines Pfads zugänglich und
erlaubt Manipulationen von Dateien per Namen.
#ifndef Path_h
#define Path_h
#include "Stat.h"
@interface Path: Stat
{
char * path; // dynamic
}
- initPath:(const char *)path;
- (const char *)name; // path
- stat; // update attributes
- lstat; // update attributes
- chmod:(short)mode; // change mode
- unlink; // remove
@end
#endif
stat und lstat aktualisieren die Stat-Information, wobei lstat einen symbolischen
Link als solchen zeigt und stat dem Link folgt und das Zielobjekt untersucht.
2-9

Fd
Ein Fd-Objekt verkapselt den File-Deskriptor, der dem Betriebssystem gegenüber als
Dateiverbindung gilt. Falls bekannt, wird der zur Erzeugung verwendete Dateiname für
Fehlermeldungen aufbewahrt.
#ifndef Fd_h
#define Fd_h
#include
#include "Stat.h"
@interface Fd: Stat // "abstract" base class
{
int fd; // -1 or open file descriptor
char * path; // dynamic, if known
}
- close; // free implies close
- fstat; // update attributes
- (long)lseek:(long)pos from:(int)where;
- (const char *)name; // path or fd
@end
Als gemeinsame Basisklasse enthält Fd die Methoden, die allen File-Deskriptoren
gemeinsam sind.
Diese Klasse soll abstrakt sein, deshalb ist die Initialisierungsmethode in einer privaten
Definitionsdatei FdP.h versteckt:
#ifndef FdP_h
#define FdP_h
#include "Fd.h"
@interface Fd (private)
+ open:(const char *)_path flags:(int)flags mode:(int)mode;
// initFd:open(...)
- initFd:(int)_fd io:(int)want; // designated init’er
@end // ..checks flags for want
@interface ReadFd (private)
- transfer:fout; // common code of cat: and cp:
@end
#endif
open:flags:mode: soll ein Objekt einer Unterklasse von Fd erzeugen, initFd:io: prüft,
ob der gewünschte Zugriff auch möglich ist.
Die Unterklassen sollen initFd: implementieren, damit auch eine Zahl in ein Fd-Objekt
verkapselt werden kann:
@protocol Fd // implemented only in subclasses
- initFd:(int)fd; // check and wrap number as Fd
@end
2-10

ReadFd und WriteFd
Dateiverbindungen können nur für Lesezugriff, nur für Schreibzugriff oder für beides
zugelassen sein, folglich gibt es Protokolle für die Transfermethoden und Unterklassen
ReadFd und WriteFd, die nur die möglichen Operationen als Methoden besitzen.
@protocol Read // implemented by readable Fd
- (int)read:(void *)buf len:(int)len;
@end
@interface ReadFd: Fd
+ open:(const char *)path;
- cat:fout; // [fout cat:self] || append contents to fout
- cp:fout; // [fout cp:self] || replace contents of fout
@end
open: greift auf eine existente Datei zu. read:len: versucht, einen Puffer zu füllen und
liefert die Anzahl transferierter Bytes, die auch Null sein kann.
cat: hängt den eigenen Inhalt an eine andere Dateiverbindung an, cp: soll den anderen
Inhalt ersetzen. Beide Methoden geben dem Partner Vorrang, die Operation selbst
durchzuführen; damit kann für eine abgebildete Datei effizienter verfahren werden.
@protocol Write // implemented by writable Fd
- (int)write:(const void *)buf len:(int)len;
@end
@interface WriteFd: Fd
+ create:(const char *)path mode:(int)mode;
@end
create:mode: erzeugt eine neue Datei mit Zugriffsschutz oder schneidet eine existente
Datei auf Länge Null zurück. write:len: versucht, einen Puffer zu schreiben und liefert
die Anzahl transferierter Bytes, die je nach Dateiverbindung auch weniger als
gewünscht sein kann.
2-11

PrintFd
PrintFd ist eine Unterklasse von WriteFd, die einfache Methoden zur formatierten
Textausgabe besitzt.
@interface PrintFd: WriteFd // formatted printing above WriteFd
{
id wfd; // WriteFd as transport
FILE * fp; // pushed on top
}
- initPrintFd:wfd; // designated init’er
- flush; // empty buffer
- (int)putc:(char)ch; // all return -1 or #bytes output
- (int)puts:(const char *)string;
- (int)printf:(const char *)fmt, ...; // might return 0 on NeXT ??
- (int)printf:(const char *)fmt :(va_list)ap;
@end
Ein PrintFd-Objekt kann entweder mit initFd: initialisiert oder mit initPrintFd: auf
einen vorhandenen WriteFd aufgesetzt werden, über den dann die Kontrolle
übernommen wird.
Die Ausgabe-Methoden sind auf die stdio-Funktionen abgebildet, wobei die Standard-
Ausgabe zeilenweise und die Diagnose-Ausgabe nicht gepuffert wird. Falls nötig, muß
flush verwendet werden, was bei close implizit erfolgt.
Bei free wird auch der WriteFd, falls verwendet, freigegeben.
2-12

Dateien im Adreßraum
Dateien im Adreßraum
Manche Systeme können einen Teil des Prozeß-Adreßraums mit einer Datei
verknüpfen, entweder nur für Lesezugriff, oder auch für Schreibzugriff, wobei ein
Schreibzugriff auf den Speicher unmittelbar zu einer Schreiboperation in der Datei führt.
Hauptspeicher
0
1
.
.
.
end
Text
Daten
Datei
Platte
Programm
Swap-Bereich
Datei
Daten
Das Verfahren ist höchst effizient, weil unnütze Kopien im Kern des Betriebssystems
vermieden werden.
Prozeß
System
Ausgabe
Ausgabe
Eingabe
Eingabe
Platte
Eingabe
Ausgabe
Prozeß
System
Ausgabe
Eingabe
Allerdings können derartig abgebildete Dateien nur durch Ändern der Abbildung
wachsen.
Platte
Eingabe
Ausgabe
2-13

MappedReadFd
MappedReadFd bildet eine Datei für Lesezugriff ab.
#ifndef MappedFd_h
#define MappedFd_h
#include "Fd.h"
@interface MappedReadFd: ReadFd
{
const void * content; // mapped area
size_t offset, size; // begin, length
}
- initFd:(int)fd; // may return ReadFd instead
- (const void *)at:(size_t)offset len:(size_t *)lenp;
@end
Es bleibt offen, ob man eine Datei ganz abbilden kann. at:lenp: versucht, möglichst
viel von einer Anfangsposition in der Datei ab zur Verfügung zu stellen und liefert auch
die benutzbare Länge. Falls das Dateiende erreicht wurde, ist das Resultat NULL.
MappedWriteFd
MappedWriteFd versucht, eine Datei für Schreibzugriff abzubilden. Das ist nicht auf jeder
UNIX-Plattform (effizient) möglich.
@interface MappedWriteFd: WriteFd
{
void * content; // mapped area
size_t offset, size; // begin, length
}
- initFd:(int)fd; // may return WriteFd instead
- (void *)at:(size_t)offset size:(size_t)size;
@end
#endif
Es bleibt offen, ob eine Datei implizit oder explizit geschrieben wird. at:len: versucht,
von einer Anfangsposition ab einen vorgeschriebenen Bereich zum Schreiben
bereitzustellen, dabei muß am Schluß ein Null-Byte eingefügt werden.
2-14

Dateien kopieren
Dateien kopieren — cp
cp interpretiert seine Argumente als Dateinamen und kopiert entweder die erste Datei
in die zweite, oder alle Dateien in den Katalog, den das letzte Argument bezeichnet.
cp illustriert, wie man Dateien erzeugt und ihren Zugriffsschutz anpaßt.
cp wird in sechs Schritten verfeinert:
cp0 ist eine triviale Lösung.
cp1 versucht, die Eingabedatei abzubilden.
cp2 versucht, beide Dateien abzubilden.
cp3 vermeidet, daß die Eingabedatei als Ausgabedatei verwendet wird.
cp4 übernimmt für Dateien den Zugriffsschutz und löscht die Ausgabedatei bei
Fehlern.
cp5 verwendet ein Cp-Objekt, mit dem auch in einen Katalog kopiert werden
kann.
Hauptprogramm für cp
Das Hauptprogramm erzeugt ein Cp-Objekt als Klient von Main und erklärt Details einer
etwaigen Exception.
#include "Cp.h"
#include "Fd.h"
#include "Main.h"
int main (int argc, char * argv []) {
id handler = [Handler new];
}
if (catch(handler)) {
id e = [handler exception];
if (! [e isKindOf:[IOException class]])
[mainFrame error:"usage: %s from ... to", [mainFrame progname]];
[mainFrame fatal:"%s: %s", [[e class] name], [e info]];
}
[[Main alloc] initMain:argv[0]]; // progname is set
if (argc < 3)
[Exception throw:"bad argument count"];
[mainFrame setClient:[[Cp alloc] initPath:argv[argc-1]]];
argv[-- argc] = 0;
[mainFrame run:argv];
return 0;
Cp soll mit arg: nur die Eingabedateien verarbeiten, deshalb wird das letzte Argument
vorher als Ziel an Cp übergeben. Damit Fehlermeldungen mit dem Programmnamen
markiert werden können, erhält Main ihn vorab.
2-15

Ein trivialer Klient — Cp0
Cp merkt sich den Zielpfad und (später) ob es sich um einen Katalog handelt.
#ifndef Cp_h
#define Cp_h
#include
@interface Cp: Object
{
const char * path;
BOOL isDir;
}
- initPath:(const char *)path;
@end
#endif
Damit Cp unabhängig vom Kopiervorgang verfeinert werden kann, gibt es dafür eine
Funktion copy():
#ifndef copy_h
#define copy_h
void copy (const char * from, const char * to);
#endif
Eine triviale Implementierung von Cp erlaubt nur zwei Argumente:
#include "Cp.h"
#include "Exception.h"
#include "Main.h"
#include "copy.h"
@implementation Cp
- initPath:(const char *)_path {
[super init];
path = _path;
return self;
}
- noarg {
[mainFrame fatal:"botched argument count"];
return self; // dummy
}
- arg:(const char *)arg {
if ([mainFrame length] != 1) // target is consumed...
[Exception throw:"bad argument count"];
copy(arg, path);
return self;
}
@end
noarg kann eigentlich nicht aufgerufen werden...
2-16

cp0
cp1
Die trivialste Lösung stützt sich auf eine Methode cp: von ReadFd, die genau wie cat:
auf transfer: beruht.
#include "Fd.h"
#include "copy.h"
void copy (const char * from, const char * to) {
id fin = [ReadFd open:from];
id fout = [WriteFd create:to mode:0644];
}
[fin cp:fout];
[fout free];
[fin free];
cp1 versucht, die Eingabedatei abzubilden, um dann effizienter zu kopieren.
#include "Main.h"
#include "MappedFd.h"
#include "copy.h"
void copy (const char * from, const char * to) {
id fin, fout;
fin = [MappedReadFd open:from];
if ([fin isMemberOf:[MappedReadFd class]])
[[mainFrame ferr] printf:"%s mapped\n", from];
}
fout = [WriteFd create:to mode:0644];
[fin cp:fout];
[fout free];
[fin free];
2-17

cp2
cp2 versucht, beide Dateien abzubilden.
#include "Main.h"
#include "MappedFd.h"
#include "copy.h"
void copy (const char * from, const char * to) {
id fin, fout = nil;
fin = [MappedReadFd open:from];
if ([fin isMemberOf:[MappedReadFd class]])
[[mainFrame ferr] printf:"%s mapped\n", from];
fout = [MappedWriteFd create:to mode:0644];
if ([fout isMemberOf:[MappedWriteFd class]])
[[mainFrame ferr] printf:"%s mapped\n", to];
}
[fin cp:fout];
[fout free];
[fin free];
Wenn dies gelingt, kann MappedWriteFd mit einer effizienteren Version von cp:
wesentlich effizienter kopieren:
- cp:fin {
const void * ibuf;
size_t n, len;
}
if (! [fin isKindOf:[MappedReadFd class]])
return nil;
for (n = 0; (ibuf = [fin at:n len:&len]); n += len)
memcpy([self at:n size:len], ibuf, len);
return self;
2-18

cp3
cp3 vermeidet, daß durch Erzeugen der Ausgabedatei die Eingabedatei vorzeitig
zerstört wird.
#include "Main.h"
#include "MappedFd.h"
#include "Path.h"
#include "copy.h"
void copy (const char * from, const char * to) {
id fin, fout = nil;
id path, handler;
fin = [[MappedReadFd open:from] fstat];
if ([fin isMemberOf:[MappedReadFd class]])
[[mainFrame ferr] printf:"%s mapped\n", from];
handler = [Handler new];
if (! catch(handler))
path = [[Path alloc] initPath:to], [path stat];
else // path does not exist
[path free], path = nil;
[handler free];
if ([fin isFile] && [fin isEqual:path]) {
id e = [Exception new:"\"%s\" equals \"%s\"",
[fin name], [path name]];
[fin free], [path free], [e throw];
}
[path free];
fout = [MappedWriteFd create:to mode:0644];
if ([fout isMemberOf:[MappedWriteFd class]])
[[mainFrame ferr] printf:"%s mapped\n", to];
}
[fin cp:fout];
[fout free];
[fin free];
Das Problem unterscheidet sich von cat1 dadurch, daß die Ausgabedatei als Pfad
untersucht werden muß. W enn sie nicht existiert, ist das besonders erfreulich.
2-19

cp4
cp4 gibt einer (neuen?) Ausgabedatei den Zugriffsschutz der Eingabedatei. Bei
Mißerfolg werden die Spuren vertilgt und die internen Objekte freigegeben.
#include "Main.h"
#include "MappedFd.h"
#include "Path.h"
#include "copy.h"
void copy (const char * from, const char * to) {
id fin, fout = nil;
id path, handler;
fin = [[MappedReadFd open:from] fstat];
if ([fin isMemberOf:[MappedReadFd class]])
[[mainFrame ferr] printf:"%s mapped\n", from];
if ([fin isDir]) {
id e = [Exception new:"\"%s\" is directory ", [fin name]];
[fin free], [e throw];
}
path = [[Path alloc] initPath:to];
handler = [Handler new];
if (! catch(handler)) {
[path stat];
[handler disarm];
if ([fin isFile] && [fin isEqual:path]) {
id e = [Exception new:"\"%s\" equals \"%s\"",
[fin name], [path name]];
[handler free], [path free], [fin free], [e throw];
}
}
fout = [MappedWriteFd create:to mode:0644];
if ([fout isMemberOf:[MappedWriteFd class]])
[[mainFrame ferr] printf:"%s mapped\n", to];
}
if (! catch(handler)) {
[fin cp:fout];
if ([fin isFile] && [[fout fstat] isFile])
[path chmod:[fin mode]];
} else { // may be entered more than once
id x;
if (path)
x = path, path = nil, [x unlink], [x free];
if (fout)
x = fout, fout = nil, [x free];
if (fin)
x = fin, fin = nil, [x free];
[handler rethrow];
}
[handler free], [path free], [fout free], [fin free];
Das Problem ist diffizil, weil man Folgefehler sorgfältig intern abfangen muß.
2-20

cp5
Für cp5 wird Cp anders implementiert, damit man viele Dateien in einen Katalog
kopieren kann.
#include "Cp.h"
#include "Fd.h"
#include "Main.h"
#include "Path.h"
#include "copy.h"
@implementation Cp
- initPath:(const char *)_path {
id handler, dir;
[super init];
path = _path;
handler = [Handler new];
if (! catch(handler)) {
dir = [[Path alloc] initPath:path];
isDir = [[dir stat] isDir];
}
[dir free], [handler free];
return self;
}
- noarg {
[mainFrame fatal:"botched argument count"];
return self; // dummy
}
- arg:(const char *)arg {
const char * fnm;
if (isDir) { // attach basename to path
const char * basename = arg;
if ((fnm = strrchr(arg, ’/’))) // bug: path// gets botched
basename = fnm+1;
fnm = alloca(strlen(path)+1 + strlen(basename)+1);
sprintf((char *)fnm, "%s/%s", path, basename);
} else if ([mainFrame length] != 1) // is it: cp old newname ??
[Exception throw:"bad argument count"];
else // use path as name
fnm = path;
copy(arg, fnm);
return self;
}
@end
2-21

2-22

Systemaufrufe testen
Systemaufrufe testen
fd ist ein einfaches Programm, mit dem man verschiedene Systemaufrufe zum Datei-
Management testen kann.
usage: fd command...
close -c fd
dup -d fd
fstat -f fd
lseek -l fd pos from
open -o path r|w[tca] mode
read -r fd len
stat -s path
unlink -u path
write -w fd text
fd demonstriert, wie man mit der gleichen prinzipiellen Architektur sowohl Argumente
von der Kommandozeile als auch aus Dateien bearbeiten kann.
Mit fd kann man eine Reihe unangenehmer Fragen im Bereich dieser Systemaufrufe
experimentell untersuchen. Die Resultate sind nicht bei allen Plattformen gleich.
fd ist ein typisches Programm zur Klärung derartiger Probleme: man muß die
Systemaufrufe möglichst einzeln und direkt ausführen können, man muß ihre Resultate
ganz genau sehen, und man muß die richtigen Beispiele durchprobieren.
3-1

Beispiele
$ echo 0123456789 > 0123456789
$ { fd -l0 5 0 & wait; read x; echo $x; } < 0123456789 2> /dev/null
Auf NeXT liefert dieses Beispiel — wie beabsichtigt — die Zeichenkette 56789.
Auf Linux erhält man 0123456789.
Des Rätsels Lösung ist, daß bash auf Linux dem Hintergrundprozeß /dev/null als
Standard-Eingabe liefert, wohingegen sh auf NeXT korrekterweise Zugriff auf die Datei
beläßt.
Andererseits sieht man auch Folgendes:
$ fd -f0 < 0123456789
fstat 0 -> 0: dev 0x2, ino 31236, mode 0100644, nlink 1, uid 200, gid 0, rdev
0x0, size 11
$ fd -f0 0: dev 0x2, ino 31236, mode 0100644, nlink 1, uid 200, gid 0, rdev
0x0, size 11
$ ls -l `tty`
2298 crw--w---- 1 axel tty 4, 192 May 18 08:03 /dev/ttyp0
$ fd -f0
fstat 0 -> 0: dev 0x302, ino 2298, mode 020620, nlink 1, uid 200, gid 5, rdev
0x4c0, size 0
$ fd -f0 &
fstat 0 -> 0: dev 0x302, ino 2298, mode 020620, nlink 1, uid 200, gid 5, rdev
0x4c0, size 0
Hier wird offensichtlich sowohl eine Datei als auch das Terminal an den
Hintergrundprozeß übergeben — das liegt daran, daß im interaktiven Bereich Job-
Control dafür sorgt, daß der Zugriff zum Terminal korrekt erfolgt...
Enthält die ausführbare Datei skript folgendes:
#!/bin/sh
fd -f0 &
dann sieht man:
$ skript
fstat 0 -> 0: dev 0x302, ino 2129, mode 020666, nlink 1, uid 0, gid 3, rdev
0x103, size 0
$ . skript
fstat 0 -> 0: dev 0x302, ino 2298, mode 020620, nlink 1, uid 200, gid 5, rdev
0x4c0, size 0
Im ersten Fall wird ‘‘korrekt’’ /dev/null an den Hintergrundprozeß angeschlossen, im
zweiten Fall bleibt es wegen Job-Control beim Terminal /dev/ttyp0.
Weitere, interessante Beispiele sind Untersuchungen zu nahezu gleichzeitigem
Lesezugriff und neuem Erzeugen einer Datei sowie Verwenden und Löschen einer
Datei.
3-2

Implementierung
Implementierung — fd/fd.m
Im Hauptprogramm wird das übliche Framework eingerichtet. Außerdem werden Fd-
Objekte für stdio und ein List-Objekt zur Verwaltung der Fd-Objekte erzeugt:
#include
#include
#include "FdP.h"
#include "Main.h"
#include "Path.h"
#define USAGE "usage: %s command...\n" \
"close -c fd\n" \
"dup -d fd\n" \
"fstat -f fd\n" \
"lseek -l fd pos from\n" \
"open -o path r|w[tca] mode\n" \
"read -r fd len\n" \
"stat -s path\n" \
"unlink -u path\n" \
"write -w fd text"
#define DELIM " \t\n"
static id fds; // List managing all Fd objects
static id fin, fout, ferr; // stdin, stdout, stderr
typedef const char * a; // pass all arguments as strings
...
int main (int argc, char * argv []) {
id handler = [Handler new];
}
if (catch(handler)) {
id e = [handler exception];
if (! [e isKindOf:[IOException class]])
[mainFrame error:USAGE, [mainFrame progname]];
[mainFrame fatal:"%s: %s", [[e class] name], [e info]];
}
[[Main new] setClient:[Object new]];
fds = [List new];
fin = [fds put:[mainFrame fin] at:0];
fout = [fds put:[mainFrame fout] at:1];
ferr = [fds put:[mainFrame ferr] at:2];
[mainFrame run:argv];
return 0;
3-3

Ein erweitertes List-Objekt verwaltet Fd-Objekte und erlaubt Systemaufrufe:
@interface List (fds) // vector of Fd objects, runs commands
- at:(int)fd; // returns List[fd] (must be Fd)
- put:fd at:(int)n; // returns List[n] = fd (nil or fd)
- close:(a)fd; // Fd system calls
- dup:(a)fd;
- fstat:(a)fd;
- lseek:(a)fd :(a)pos :(a)from;
- open:(a)path :(a)flags :(a)mode;
- read:(a)fd :(a)len;
- stat:(a)path;
- unlink:(a)path;
- write:(a)fd :(a)text;
@end
Das List-Objekt dient als Vektor; leere Positionen werden mit V erweisen auf List
selbst gefüllt. at: liefert ein Fd-Objekt nach Nummer:
@implementation List (fds)
- at:(int)fd {
id result = [self objectAt:fd];
}
if (! result || ! [result isKindOf:[Fd class]])
[IOException throw:"%d: no such fd", fd];
return result;
put:at: fügt ein Fd-Objekt ein und füllt etwaige Zwischenräume:
- put:fd at:(int)n {
int i;
}
for (i = [self count]; i

ead:: liest ein und kopiert zur Standard-Ausgabe, die von der Shell her unterdrückt
werden könnte.
- read:(a)_fd :(a)_len {
int fd = atoi(_fd), len = atoi(_len);
id ofd;
}
[ferr printf:"read %d %d -> ", fd, len];
if ([ofd = [self at:fd] respondsTo:@selector(read:len:)]) {
void * area = len ? alloca(len) : alloca(1);
len = [ofd read:area len:len];
[ferr printf:"%d \"%.*s\"\n", len, len, area];
[fout write:area len:len];
} else
[IOException throw:"%d: cannot read fd", fd];
return self;
write:: schreibt einen Text.
- write:(a)_fd :(a)text {
int fd = atoi(_fd);
id ofd;
[ferr printf:"write %d \"%s\" -> ", fd, text];
if ([ofd = [self at:fd] respondsTo:@selector(write:len:)])
[ferr printf:"%d\n", [ofd write:text len:strlen(text)]];
else
[IOException throw:"%d: cannot write fd", fd];
return self;
}
@end
lseek::: positioniert.
- lseek:(a)_fd :(a)_pos :(a)_from {
int fd = atoi(_fd), pos = atoi(_pos), from = atoi(_from);
}
[ferr printf:"lseek %d %d %d -> ", fd, pos, from];
[ferr printf:"%d\n", [[self at:fd] lseek:pos from:from]];
return self;
unlink: entfernt eine Pfadkomponente.
- unlink:(a)path {
id opath = [[Path alloc] initPath:path];
}
[ferr printf:"unlink %s -> ", path];
[opath unlink];
[ferr puts:"0\n"];
[opath free];
return self;
fstat: und stat: holen und zeigen die Attribute.
3-5

- fstat:(a)_fd {
int fd = atoi(_fd);
id ofd;
}
[ferr printf:"fstat %d -> ", fd];
ofd = [[self at:fd] fstat];
[ferr puts:"0: "];
[ofd displayOn:ferr], [ferr putc:’\n’];
return self;
- stat:(a)path {
id opath = [[Path alloc] initPath:path];
}
[ferr printf:"stat %s -> ", path];
[opath stat];
[ferr puts:"0: "];
[opath displayOn:ferr], [ferr putc:’\n’];
[opath free];
return self;
Dazu wird eine Erweiterung der Klasse Stat verwendet:
@interface Stat (displayOn) // need to display stat fields
- displayOn:fd;
@end
@implementation Stat (displayOn)
- displayOn:fd {
[fd printf:"dev 0x%x, ", s.st_dev];
[fd printf:"ino %d, ", s.st_ino];
[fd printf:"mode 0%o, ", s.st_mode];
[fd printf:"nlink %d, ", s.st_nlink];
[fd printf:"uid %d, ", s.st_uid];
[fd printf:"gid %d, ", s.st_gid];
[fd printf:"rdev 0x%x, ", s.st_rdev];
[fd printf:"size %d", s.st_size];
return self;
}
@end
3-6

Etwas aufwendiger sind Systemaufrufe, bei denen Fd-Objekte erzeugt oder gelöscht
werden.
- dup:(a)_fd {
int fd = atoi(_fd), n;
id ofd;
}
[ferr printf:"dup %d -> ", fd];
ofd = [self at:fd];
[ferr printf:"%d\n", n = dup(fd)];
if (n >= 0)
[self put:[[[ofd class] alloc] initFd:n] at:n];
return self;
dup: erzeugt ein neues Fd-Objekt und trägt es in die List ein.
- open:(a)path :(a)_flags :(a)_mode {
char * dummy;
int flags = 0, mode = strtol(_mode, &dummy, 0);
id class = nil, fd;
}
if (strchr(_flags, ’r’)) flags |= O_RDONLY, class = [ReadFd class];
else if (strchr(_flags, ’w’)) flags |= O_WRONLY, class = [WriteFd class];
if (strchr(_flags, ’a’)) flags |= O_APPEND;
if (strchr(_flags, ’c’)) flags |= O_CREAT;
if (strchr(_flags, ’t’)) flags |= O_TRUNC;
[ferr printf:"open %s %s 0%o -> ", path, _flags, mode];
fd = [class open:path flags:flags mode:mode];
[ferr printf:"%d\n", [fd fd]];
if (fd)
[self put:fd at:[fd fd]];
return self;
open::: geht zum verborgenen Initializer, um beliebige Flaggen verwenden zu können.
Hier ist eine zusätzliche Methode in Fd nötig:
@interface Fd (fd) // need to get to fd number
- (int)fd;
@end
@implementation Fd (fd)
- (int)fd {
return fd;
}
@end
close: könnte prinzipiell ein Fd-Objekt aus der List entfernen, aber es wird nur
unverwendbar hinterlassen, bis es bei einem erneuten open oder dup überschrieben
wird.
- close:(a)_fd {
int fd = atoi(_fd);
}
[ferr printf:"close %d -> ", fd];
[[self at:fd] close];
[ferr puts:"0\n"];
return self;
3-7

Jetzt können die Systemaufrufe sehr leicht von der Kommandozeile aus aufgerufen
werden. Hier zahlt sich die Verwendung des Frameworks aus:
@implementation Object (svcs) // Main client
- flag:(char)ch { // run from command line
a fd, pos, path, flags;
switch (ch) {
case ’c’: return [fds close:[mainFrame nextarg]];
case ’d’: return [fds dup:[mainFrame nextarg]];
case ’f’: return [fds fstat:[mainFrame nextarg]];
case ’l’: fd = [mainFrame nextarg];
pos = [mainFrame nextarg];
return [fds lseek:fd :pos :[mainFrame nextarg]];
case ’o’: path = [mainFrame nextarg];
flags = [mainFrame nextarg];
return [fds open:path :flags :[mainFrame nextarg]];
case ’r’: fd = [mainFrame nextarg];
return [fds read:fd :[mainFrame nextarg]];
case ’s’: return [fds stat:[mainFrame nextarg]];
case ’u’: return [fds unlink:[mainFrame nextarg]];
case ’w’: fd = [mainFrame nextarg];
return [fds write:fd :[mainFrame nextarg]];
default: return [mainFrame flag:ch];
}
return self;
}
- noarg { // ok to have no arguments
return self;
}
Wenn man auch Kommandos in einer Datei angeben will, muß man arg:
implementieren:
- arg:(const char *)arg { // run argument file
FILE * fp;
char buf [BUFSIZ];
id handler;
if (strcmp(arg, "-") == 0)
fp = stdin, clearerr(stdin);
else if (! (fp = fopen(arg, "r")))
[IOException throw:errno info:arg];
handler = [Handler new]; // in this case, continue after error
if (catch(handler)) {
id e = [handler exception];
}
[mainFrame error:"%s: %s", [[e class] name], [e info]];
Ein eigener Handler sorgt dafür, daß in diesem Fall Fehler einigermaßen
stillschweigend vergeben werden. Die Zeilen zerpflückt man mit stdio und strtok():
3-8

while (fgets(buf, sizeof buf, fp)) {
a cmd;
if ((cmd = strtok(buf, DELIM))) {
a fd, pos, from, path, flags, mode, len, text;
}
}
[handler free];
if (fp != stdin)
fclose(fp);
return self;
}
@end
cmd += cmd[0] == ’-’; // optional -
switch (cmd[0]) {
case ’#’: continue;
case ’c’: if (! (fd = strtok(0, DELIM))) break;
[fds close:fd]; continue;
case ’d’: if (! (fd = strtok(0, DELIM))) break;
[fds dup:fd]; continue;
case ’f’: if (! (fd = strtok(0, DELIM))) break;
[fds fstat:fd]; continue;
case ’l’: if (! (fd = strtok(0, DELIM))
|| ! (pos = strtok(0, DELIM))
|| ! (from = strtok(0, DELIM))) break;
[fds lseek:fd :pos :from]; continue;
case ’o’: if (! (path = strtok(0, DELIM))
|| ! (flags = strtok(0, DELIM))
|| ! (mode = strtok(0, DELIM))) break;
[fds open:path :flags :mode]; continue;
case ’r’: if (! (fd = strtok(0, DELIM))
|| ! (len = strtok(0, DELIM))) break;
[fds read:fd :len]; continue;
case ’s’: if (! (path = strtok(0, DELIM))) break;
[fds stat:path]; continue;
case ’u’: if (! (path = strtok(0, DELIM))) break;
[fds unlink:path]; continue;
case ’w’: if (! (fd = strtok(0, DELIM))
|| ! (text = strtok(0, DELIM))) break;
[fds write:fd :text]; continue;
}
[ferr printf:USAGE "\n", [mainFrame progname]];
Dank der Systemaufrufe im List-Objekt kann ein wesentlicher Teil des Codes
wiederverwendet werden, obgleich eine völlig andere Strategie zur Fehlerbehandlung
verfolgt wird.
3-9

3-10

Dateinamen
Dieser Abschnitt beschäftigt sich mit Systemaufrufen zum Zugriff auf Dateien als Ganzes und mit Klassen zum Umgang mit diesen
Systemaufrufen.
Filename verkapselt einen Dateinamen.
Themen
• Dateimanipulationen
Systemaufrufe
• access
• chdir
• chmod
• chown
• chroot
• close
• creat
• dup, dup2
• fcntl
• link
• lock
• lseek
• mkdir
• mknod
• mmap, munmap
• mount, umount
• open
• pipe
• read
• readdir
• readlink
• rename
• rmdir
• stat, lstat, fstat
• statfs
• truncate
• unlink
• write
Wichtige Bibliotheksfunktionen
• perror
• strerror
1996/5/20
1996/5/20

Transfer-Operationen -- cat
cat interpretiert seine Argumente als Dateinamen und kopiert die Inhalte zur Standard-Ausgabe. Ohne Argumente oder für jedes
Argument - wird von der Standard-Eingabe kopiert.
cat illustriert Dateizugriff mit der Klasse Fd und die Transfer-Operationen..
#include "Fd.h"
#include "Main.h"
@implementation Object (cat)
- fd:fd {
return [fd cat:[mainFrame fout]];
}
@end
1996/5/20
1996/5/20

Implementierung der Datei-Klassen
Implementierung der Datei-Klassen
Dieser Abschnitt beschäftigt sich mit der Implementierung der Klassen zum Umgang
mit Dateien. Die Funktionalität wurde im Abschnitt Klassen für Dateien vorgestellt.
Klassen
Systemaufrufe
Stat — Information über ein Objekt im Dateisystem
IOException — Fehler beim Umgang mit Dateien
Fd — File-Deskriptor, Dateiverbindung
ReadFd — Lesezugriff
WriteFd — Schreibzugriff
PrintFd — formatierte Ausgabe
MappedReadFd — Abbildung zum Lesen
MappedWriteFd — Abbildung zum Schreiben (und Lesen)
Path — Dateiname
chmod
close
creat
dup, dup2
fcntl
fstat
lseek
lstat, stat
map_fd
mmap, munmap
open
read
unlink
write
vm_deallocate
5-1

Wichtige Bibliotheksfunktionen
fclose
fdopen
memcpy
setvbuf
5-2

Stat — Implementierung
Stat — Implementierung
Ein Stat-Objekt verkapselt die Information, die vom Betriebssystem über ein Objekt im
Dateisystem zu erfahren ist.
Diese Information wird in einer struct stat abgelegt und in den Unterklassen von Stat
mit Systemaufrufen wie stat() angefordert.
- (BOOL)isEqual:obj {
if (obj == self)
return YES;
if ([obj isKindOf:[Stat class]])
{ Stat * sp = obj;
}
if (s.st_dev == sp->s.st_dev && s.st_ino == sp->s.st_ino)
return YES;
}
return NO;
isEqual: ist eine Methode von Object, die Objekt-Äquivalenz implementieren soll. Für
File-Deskriptoren und Dateinamen muß das Problem auf die Gleichheit der dahinter
befindlichen Inodes zurückgeführt werden. Nur die Kombination aus Inode-Nummer st
_ino und Gerätenummer st_dev ist eindeutig — dies gilt auch für Dateien im NFS.
- (short)mode {
return s.st_mode & ~S_IFMT;
}
st_mode enthält den Zugriffsschutz und die Art der Inode. Damit kann man unter
anderem bestimmen, ob es sich um eine Datei oder einen Katalog handelt:
- (BOOL)isFile {
return (s.st_mode & S_IFMT) == S_IFREG;
}
- (BOOL)isDir {
return (s.st_mode & S_IFMT) == S_IFDIR;
}
st_size enthält die Größe einer Datei oder eines Katalogs. Bei Geräten ist die
Bedeutung nicht standardisiert.
- (long)size {
return s.st_size;
}
5-3

IOException — Implementierung
Bei Dateizugriff kann es viele Fehler geben. Damit sie von anderen Fehlern
unterschieden werden können, gibt es die Klasse IOException, die zusammen mit Stat
implementiert wird.
@implementation IOException
@end
5-4

Fd — Implementierung
Fd — Implementierung
Ein Fd-Objekt verkapselt den File-Deskriptor, der dem Betriebssystem gegenüber als
Dateiverbindung gilt.
Falls bekannt, wird der zur Erzeugung verwendete Dateiname für Fehlermeldungen
aufbewahrt, deshalb muß Fd die üblichen Methoden zur Verwaltung eines
dynamischen Strings enthalten.
Dateiverbindung erzeugen — open oder creat
int open (const char * path, int flags, ...);
int creat (const char * path, int mode);
open() richtet eine Dateiverbindung zu path ein, je nach flags zum Lesen mit
O_RDONLY, Schreiben mit O_WRONLY oder zu beidem mit O_RDWR. Die Datei kann dabei mit
O_CREATauch erzeugt oder auf Länge Null abgeschnitten werden mit O_TRUNC. Zum
Erzeugen ist ein drittes Argument mode nötig.
creat() erzeugt eine Datei path mit Zugriffsschutz mode, oder schneidet eine existente
Datei auf Länge Null ab und liefert Schreibzugriff.
Dies ist in einer privaten Methode in Fd verkapselt, die leere Dateinamen abwehrt und
den Dateinamen für Fehlermeldungen speichert:
+ open:(const char *)_path flags:(int)flags mode:(int)mode {
int f;
Fd * result;
}
if (! _path || ! _path[0])
[IOException throw:"null filename"];
if ((f = open(_path, flags, mode)) == -1)
[IOException throw:errno info:"open \"%s\"", _path];
if ((result = [[self alloc] initFd:f]) // may be nil
&& (result->path = malloc(strlen(_path)+1)))
strcpy(result->path, _path);
return result;
- (const char *)name {
if (! path)
{ char buf [20];
}
sprintf(buf, "fd %d", fd);
if ((path = malloc(strlen(buf)+1)))
strcpy(path, buf);
}
return path ? path : "?";
5-5

Eigenschaften einer Dateiverbindung prüfen oder setzen — fcntl
int fcntl (const char * path, int flag, ...);
Je nach flag kontrolliert fcntl() verschiedene Aspekte einer Dateiverbindung. Mit
F_GETFL kann man sehen, für welche Art von Transfer die Verbindung eröffnet wurde.
Da Fd-Objekte auch für Zahlen erzeugt werden können, prüft initFd:io:, ob sich der
File-Deskriptor für den gewünschten Zugriff eignet:
- initFd:(int)_fd io:(int)want {
[super init];
fd = _fd;
if (fd >= 0)
{ int io = fcntl(fd, F_GETFL, 0) & 3;
}
if (io != O_RDWR && io != want) {
id e = [IOException new:"\"%s\": fd mode mismatch", [self name]];
[self free], [e throw];
}
} else if (want != -1) { // can set fd = -1 with want == -1
id e = [IOException new:"\"%s\": invalid fd", [self name]];
[self free], [e throw];
}
return self;
Fd soll eine abstrakte Klasse sein. init verbietet, daß es uninitialisierte Fd-Objekte gibt.
free muß auf jeden Fall den File-Deskriptor und den Dateinamen freigeben.
- init {
return [self subclassResponsibility:_cmd];
}
- free {
[self close];
free(path), path = 0;
return [super free];
}
Dateiverbindung freigeben — close
int close (int fd);
close() gibt eine Dateiverbindung frei.
- close {
if (fd >= 0) {
int result = close(fd);
}
fd = -1;
if (result == -1)
[IOException throw:errno info:"close \"%s\"", [self name]];
}
return self;
5-6

Attribute einer Dateiverbindung — fstat
int fstat (int fd, struct stat * sp);
fstat() legt die Attribute für fd in *sp ab.
- fstat {
if (fstat(fd, &s) == -1)
[IOException throw:errno info:"fstat \"%s\"", [self name]];
return self;
}
Positionieren — lseek
long lseek (int fd, long pos, int where);
lseek() positioniert, falls möglich, die Dateiverbindung fd relativ zu where, so daß der
nächste Lese- oder Schreibzugriff ab pos erfolgt, und liefert die neue absolute Position.
Bei where bedeutet 0 den Dateianfang, 1 die aktuelle Position und 2 das Dateiende.
Löcher (durch Nullzeiger effizient repräsentierte große Null-Flächen in einer Datei)
entstehen durch lseek() weit hinter ein Dateiende gefolgt von einer Schreiboperation.
- (long)lseek:(long)pos from:(int)where {
long result = lseek(fd, pos, where);
}
if (result == -1)
[IOException throw:errno info:"lseek \"%s\"", [self name]];
return result;
Prozeß
Prozeß
Benutzer System
Fd per Prozeß
Positionszeiger aktive Inodes
a
b
Blöcke der Platten
Positionen können durch dup() und fork() zu mehreren File-Deskriptoren gehören.
5-7

ReadFd — Implementierung
ReadFd — Implementierung
ReadFd dient zum Lesezugriff.
Die Initialisierung erfolgt mit den vererbten Methoden von Fd:
@implementation ReadFd
+ open:(const char *)_path {
return [self open:_path flags:O_RDONLY mode:0];
}
- initFd:(int)_fd {
return [super initFd:_fd io:O_RDONLY];
}
Einlesen — read
int read (int fd, void * buf, int len);
read() transferiert bis zu len Bytes von fd zu buf im Prozeß, setzt den Positionszeiger
weiter und liefert die Anzahl der übertragenen Bytes. Nach Konvention(!) gilt 0 als
Datei-Ende.
- (int)read:(void *)buf len:(int)len {
int result = read(fd, buf, len);
}
if (result < 0)
[IOException throw:errno info:"read \"%s\"", [self name]];
return result;
cat: und cp: kopieren jeweils alle Daten, wobei cp: davon ausgeht, daß der Inhalt der
Zieldatei ersetzt wird. Beide Methoden sollen je nach Unterklasse ersetzt werden, und
sie geben dem Ausgabe-Objekt die Möglichkeit, selbst tätig zu werden.
- cat:fout {
if (! [fout isKindOf:[WriteFd class]])
[self error:"cannot use %s\n", [[fout class] name]];
if (! [fout respondsTo:@selector(cat:)] || ! [fout cat:self])
[self transfer:fout];
return self;
}
- cp:fout {
if (! [fout isKindOf:[WriteFd class]])
[self error:"cannot use %s\n", [[fout class] name]];
if (! [fout respondsTo:@selector(cp:)] || ! [fout cp:self])
[self transfer:fout];
return self;
}
In ReadFd stützen sich beide Methoden auf die private Methode transfer:.
5-8

- transfer:fout {
int n;
char buf [BUFSIZ];
}
while ((n = [self read:buf len:sizeof buf]))
if ([fout write:buf len:n] != n)
[IOException throw:errno info:"write \"%s\"", [fout name]];
return self;
WriteFd — Implementierung
WriteFd dient zum Schreibzugriff.
Die Initialisierung erfolgt mit den vererbten Methoden von Fd, wobei allerdings der
Zugriffsschutz einer neuen Datei als Argument angegeben werden kann.
@implementation WriteFd
+ create:(const char *)_path mode:(int)mode {
return [self open:_path flags:O_WRONLY|O_CREAT|O_TRUNC mode:mode];
}
- initFd:(int)_fd {
return [super initFd:_fd io:O_WRONLY];
}
- (int)write:(const void *)buf len:(int)len
{ int result = write(fd, buf, len);
if (result < 0)
[IOException throw:errno info:"write \"%s\"", [self name]];
return result;
}
@end
Ausgeben — write
int write (int fd, const void * buf, int len);
write() transferiert bis zu len Bytes von buf im Prozeß zu fd, setzt den Positionszeiger
weiter und liefert die Anzahl der übertragenen Bytes, die unter Umständen geringer als
verlangt sein kann.
5-9

PrintFd — Implementierung
PrintFd — Implementierung
PrintFd ist eine Unterklasse von WriteFd, die einfache Methoden zur formatierten
Textausgabe besitzt.
Eine relativ elegante Lösung besteht darin, daß PrintFd mit fdopen() einen FILE* auf
einen File-Deskriptor aufsetzt, um dann die üblichen Funktionen zur formatierten
Ausgabe zu nutzen. Standard- und Diagnose-Ausgabe werden mit setvbuf()
zeilenweise bzw. gar nicht gepuffert.
#include
#include "Fd.h"
@implementation PrintFd
- initPrintFd:_wfd {
if (! [_wfd respondsTo:@selector(write:len:)])
[self error:"cannot use %s\n", [[_wfd class] name]];
[super initFd:((PrintFd *)_wfd)->fd]; // circumvent protected
wfd = _wfd;
if (! (fp = fdopen(fd, "w"))) {
id e = [IOException new:errno info:"cannot create fp for \"%s\"",
[_wfd name]];
[self free], [e throw];
}
switch (fd) {
case 1: setvbuf(fp, 0, _IOLBF, 0); break; // line buffer stdout
case 2: setvbuf(fp, 0, _IONBF, 0); break; // unbuffered stderr
}
return self;
}
PrintFd ist eine zusätzliche Leistung, die letztlich nur write() benötigt. Damit diese
Leistung nachträglich aufgesetzt werden kann, verwendet PrintFd ein Fd-Objekt als
Aggregat, das dann allerdings als Besitz angesehen wird.
Zur Vereinfachung kann PrintFd auch auf self aufgesetzt werden, womit eine Zahl in
einen PrintFd verwandelt werden kann:
- initFd:(int)_fd {
fd = _fd; // kludge...
return [self initPrintFd:self];
}
Bei close wird der FILE* mit fclose() freigegeben — implizit damit aber auch der File-
Deskriptor:
- close {
if (fp) {
int result = fclose(fp);
}
5-10
fp = 0, ((PrintFd *)wfd)->fd = fd = -1;
if (result)
[IOException throw:errno info:"fclose \"%s\"", [self name]];
}
if (wfd != self)
[wfd close], wfd = nil;
return [super close];

(PrintFd *) umgeht die Einschränkung, daß eine Unterklasse nicht auf die
Instanzvariablen eines fremden Oberklassen-Objekts zugreifen kann.
name und free werden entsprechend angepaßt:
- (const char *)name {
return wfd != self ? [wfd name] : [super name];
}
- free {
[self close];
if (wfd != self)
[wfd free];
return [super free];
}
write:len: muß auf die stdio-Puffer Rücksicht nehmen:
- (int)write:(const void *)buf len:(int)len {
int result;
[self flush];
if ((result = write(fd, buf, len)) < 0)
[IOException throw:errno info:"write \"%s\"", [self name]];
return result;
}
- flush {
if (fflush(fp), ferror(fp))
[IOException throw:errno info:"flush \"%s\"", [self name]];
return self;
}
Damit können die neuen Methoden mit den stdio-Funktionen implementiert werden:
- (int)putc:(char)ch {
return putc(ch, fp) == ch ? 1 : -1;
}
- (int)puts:(const char *)string {
return fputs(string, fp) == EOF ? -1 : strlen(string);
}
- (int)printf:(const char *)fmt, ... {
va_list ap;
va_start(ap, fmt);
return [self printf:fmt :ap];
}
- (int)printf:(const char *)fmt :(va_list)ap {
return vfprintf(fp, fmt, ap);
}
@end
5-11

MappedReadFd — Implementierung
MappedReadFd — Implementierung
MappedReadFd bildet eine Datei für Lesezugriff ab. Bei Mach gibt es dafür eine (alte)
UNIX-Funktion map_fd(), die allerdings nur Lesezugriff ermöglicht.
Um Probleme zu vermeiden, werden hier nur Dateien, keine Geräte, abgebildet und als
Ersatz steht ein ReadFd zur Verfügung — würde kein Fd-Objekt geliefert, müßte die
aufwendige open-Operation sonst wiederholt werden.
#include
#include
#ifdef NeXT
#include
#else // linux || sun || __FreeBSD__
#include
#ifdef sun
int munmap();
#endif
#ifndef MAP_FILE
#define MAP_FILE 0
#endif
#endif
#include "FdP.h"
#include "MappedFd.h"
#ifndef MAXSIZE
#define MAXSIZE (16 * 1024 * 1024) // map at most 16 mb
#endif
@implementation MappedReadFd
- initFd:(int)_fd {
char * _path;
}
[super initFd:_fd];
if ([[self fstat] isFile])
return self;
_path = path, path = 0, fd = -1, [self free];
self = [[ReadFd alloc] initFd:_fd]; // cannot map
path = _path;
return self;
5-12

Datei abbilden — mmap
caddr_t mmap (caddr_t addr, size_t len, int prot, int flags, int fd, off_t
offset);
mmap() verknüpft len Bytes beginnend bei offset zwischen fd und dem Hauptspeicher.
addr ist ein Vorschlag, die eigentliche Adresse wird als Resultat geliefert. prot limitiert,
im Rahmen der Hardware-Möglichkeiten, den Zugriff ( PROT_READ, PROT_WRITE und
PROT_EXEC). flags definiert, unter anderem, ob beim Schreiben eine lokale Kopie
entsteht ( MAP_PRIVATE), oder ob sich Änderungen auf die Datei auswirken (MAP_SHARED).
Je nach Betriebssystem ist Schreibzugriff offenbar instabil: FreeBSD 2.0.1 bleibt
anschließend stehen, Linux verweigert ihn in frühen Versionen (es funktioniert in
1.3.88).
MappedReadFd besitzt jeweils einen abgebildeten Bereich. at:len: liefert entweder T eile
davon aus oder richtet ihn möglichst groß neu ein — es ist denkbar, daß eine Datei
nicht in den Adreßraum paßt oder daß sie wächst.
- (const void *)at:(size_t)_offset len:(size_t *)lenp {
if (content && _offset >= offset && _offset < offset+size)
{ *lenp = offset+size - _offset; // rest of mapped area
return (char *)content + _offset-offset;
}
[self unmap];
size = [[self fstat] size];
if (_offset >= size) // nothing left
{ size = 0;
return 0;
}
size -= _offset, offset = _offset; // try for rest of file
if (size > MAXSIZE)
size = MAXSIZE;
#ifdef NeXT
if (map_fd(fd, offset, (vm_offset_t *)&content, TRUE,
(vm_size_t)size) != KERN_SUCCESS) {
content = 0, offset = size = 0;
[IOException throw:errno info:"map_fd \"%s\"", [self name]];
}
#else
content = mmap(0, size, PROT_READ, MAP_FILE|MAP_SHARED, fd, offset);
if (content == (caddr_t)-1) {
content = 0, offset = size = 0;
[IOException throw:errno info:"mmap \"%s\"", [self name]];
}
#endif
*lenp = size;
return content;
}
5-13

Dateiabbildung entfernen — munmap
int munmap (caddr_t addr, size_t len);
Eine Abbildung wird entweder explizit mit munmap() entfernt oder implizit, wenn mit
mmap() eine neue Abbildung so erzwungen wird, daß sie eine vorhandene berührt. Falls
nötig wird dabei die Datei aktualisiert. close() impliziert aber munmap() nicht.
Bei Mach muß der Speicher mit vm_deallocate() dem Speichersystem zurückgegeben
werden, die Datei wird dabei nicht aktualisiert.
unmap gibt eine Abbildung frei und wird bei close (und damit bei free) aufgerufen:
- unmap { // remove previous map if any
if (content && size) {
#ifdef NeXT
if (vm_deallocate(task_self(), (vm_address_t)content,
(vm_size_t)size) != KERN_SUCCESS)
[IOException throw:errno info:"vm_deallocate \"%s\"",
[self name]];
#else
if (munmap((caddr_t)content, size) == -1)
[IOException throw:errno info:"munmap \"%s\"", [self name]];
#endif
content = 0, offset = size = 0;
}
return self;
}
- close {
[self unmap];
return [super close];
}
Damit kann MappedReadFd die transfer-Methode effizienter implementieren:
- transfer:fout {
const void * buf;
size_t n, len;
}
5-14
for (n = 0; (buf = [self at:n len:&len]); n += len)
if ([fout write:buf len:len] != len)
[IOException throw:errno info:"write \"%s\" truncated",
[self name]];
return self;

MappedWriteFd — Implementierung
MappedWriteFd — Implementierung
MappedWriteFd bildet eine Datei für Schreibzugriff ab. Das ist zum Beispiel bei Mach
nicht effizient möglich.
@implementation MappedWriteFd
+ create:(const char *)_path mode:(int)mode {
return [self open:_path flags:O_RDWR|O_CREAT|O_TRUNC mode:mode];
}
- initFd:(int)_fd {
char * _path;
[super initFd:_fd io:O_RDWR]; // oops, need both...
#ifndef __FreeBSD__ // PROT_WRITE apparently crashes kernel
if ([[self fstat] isFile])
return self;
#endif
_path = path, path = 0, fd = -1, [self free];
self = [[WriteFd alloc] initFd:_fd]; // cannot map
path = _path;
return self;
}
Wieder besitzt MappedWriteFd einen abgebildeten Bereich, der mit unmap freigegeben
wird. Bei Mach muß dann die Datei aktualisiert werden.
- unmap { // remove previous map if any
if (content && size) {
#ifdef NeXT
off_t current = [self lseek:0 from:1];
#else
#endif
if (current != offset)
[self lseek:offset from:0];
if ([self write:content len:size] != size)
[IOException throw:errno info:"write \"%s\" truncated",
[self name]];
[self lseek:current from:0];
free(content);
if (munmap(content, size) == -1)
[IOException throw:errno info:"munmap \"%s\"", [self name]];
content = 0, offset = size = 0;
}
return self;
}
- close {
[self unmap];
return [super close];
}
Der Aufbau der Abbildung ist dadurch erschwert, daß der abzubildende Bereich in der
Datei existieren muß. Existiert er nicht, muß man mit lseek:from: und write:len: für
ein Loch sorgen.
5-15

- (void *)at:(size_t)_offset size:(size_t)_size {
[self unmap];
if (_size < 1)
[IOException throw:"\"%s\": map 0 bytes", [self name]];
#ifdef NeXT
if (! (content = calloc(_size, sizeof(char))))
[self error:"no room\n"];
if (_offset < [[self fstat] size])
{ off_t current = [self lseek:0 from:1];
[self lseek:_offset from:0]; // read current content
if (read(fd, content, _size) == -1)
[IOException throw:errno info:"map read \"%s\"",
[self name]];
[self lseek:current from:0];
}
#else
if (_offset+_size > [[self fstat] size])
{ off_t current = [self lseek:0 from:1];
[self lseek:_offset+_size - 1 from:0]; // make a hole
if ([self write:"" len:1] != 1)
[IOException throw:errno info:"write \"%s\" truncated",
[self name]];
[self lseek:current from:0];
}
content = mmap(0, _size, PROT_READ|PROT_WRITE, MAP_FILE|MAP_SHARED,
fd, _offset);
if (content == (caddr_t)-1) {
content = 0;
[IOException throw:errno info:"mmap \"%s\"", [self name]];
}
#endif
offset = _offset, size = _size;
return content;
}
Damit kann dann cp: zwischen zwei Abbildungen mit Hilfe von memcpy() effizienter
implementiert werden:
- cp:fin {
const void * ibuf;
size_t n, len;
}
if (! [fin isKindOf:[MappedReadFd class]])
return nil;
for (n = 0; (ibuf = [fin at:n len:&len]); n += len)
memcpy([self at:n size:len], ibuf, len);
return self;
5-16

Path — Implementierung
Path — Implementierung
Ein Path-Objekt macht die Stat-Information mit Hilfe eines Pfads zugänglich und
erlaubt Manipulationen von Dateien per Namen.
#include
#include "Path.h"
@implementation Path
- initPath:(const char *)_path {
[super init];
if (! (path = malloc(strlen(_path)+1)))
[self free], [Exception throw:"%s: no room", _path];
strcpy(path, _path);
return self;
}
- free {
free(path), path = 0;
return [super free];
}
- (const char *)name {
return path;
}
Path verwaltet dynamische Strings mit den üblichen Methoden.
Für einen Dateinamen kann man die Stat-Information mit den Systemaufrufen stat()
und lstat() aktualisieren:
- stat {
if (stat(path, &s) == -1)
[IOException throw:errno info:"stat \"%s\"", [self name]];
return self;
}
- lstat {
if (lstat(path, &s) == -1)
[IOException throw:errno info:"stat \"%s\"", [self name]];
return self;
}
- chmod:(short)mode {
if (chmod(path, mode) == -1)
[IOException throw:errno info:"chmod \"%s\"", [self name]];
return self;
}
- unlink {
if (unlink(path) == -1)
[IOException throw:errno info:"unlink \"%s\"", [self name]];
return self;
}
@end
Manipulationen für Pfade folgen fast immer dem gleichen Muster .
5-17

Attribute einer Datei — stat
int stat (const char * path, struct stat * sp);
stat() legt die Attribute für path in *sp ab.
Attribute eines symbolischen Links — lstat
int lstat (const char * path, struct stat * sp);
lstat() legt die Attribute für path in *sp ab, wobei für einen symbolischen Link
allerdings, anders bei stat(), die Information zum Link selbst geliefert wird.
Zugriffsschutz ändern — chmod
int chmod (const char * path, int mode);
chmod() ändert den Zugriffsschutz der Inode und kann auch die speziellen Bits für set
userid, set groupid und sticky text ändern.
Name entfernen — unlink
int unlink (const char * path);
unlink() löscht die letzte Komponente von path in ihrem Katalog, darf aber keine
Kataloge löschen. Wenn auf eine Inode kein Pfad mehr verweist, wird sie freigegeben.
5-18

5-19

Prozesse
Prozesse
Dieser Abschnitt beschäftigt sich mit Prozessen und ihren verschiedenen
Gruppierungen sowie mit Prozeßmanipulation und Signalen.
Die Erklärung folgt Stevens’ Beschreibung der Verhältnisse bei POSIX, denn das wird
von System V und neueren Berkeley-Versionen realisiert. NeXT leistet dies nur bedingt.
Themen
Systemaufrufe
Prozeßbegriff
Prozeßmanipulationen
Signale
brk
chdir
chroot
execve
fork
getegid
geteuid
getgid
getgroups
getpgrp
getpid
getppid
gettimeofday
getuid
kill
killpg
pipe
profil
ptrace
sbrk
setgroups
setpgid
setpgrp
setregid
setreuid
setrlimit
settimeofday
shutdown
6-1

sigaction
sigblock
sigpause
sigpending
sigprocmask
sigreturn
sigsetmask
sigstack
sigsuspend
sigvec
sync
uname
utimes
vfork
vhangup
wait
wait3
wait4
Wichtige Bibliotheksfunktionen
signal
6-2

Prozeßbegriff
Prozeßbegriff
Ein Prozeß ist die Ausführung eines Programms — mit eventuell mit anderen
Prozessen gemeinsam genutztem Programmtext, eigenem Programmzähler, eigener
Datenfläche, eigenen Dateiverbindungen und eigenem Systemzustand wie Registern
und Speicherabbildungen.
Ein Thread oder light-weight process ist einer von mehreren unabhängigen
Programmzählern im gleichen Prozeß, also praktisch ein Prozeß, der nur einen
Programmzähler und einen kleinen Teil des Systemzustands eigenständig besitzt.
Threads gibt es nicht auf jeder UNIX-Plattform.
Aus Systemsicht besteht der Prozeßzustand aus einem proc-Element, das der Kern
ständig im Speicher hält, und einer user-Struktur, die mit dem Prozeß verdrängt wird.
Vom proc-Element aus sind beispielsweise offene Dateien im Kern erreichbar.
ps zeigt die Information in verschiedenen Formaten und mit verschiedenen Techniken
— entweder durch Zugriff auf /dev/kmem oder gar /dev/proc, oder mit einem proc-
Dateisystem. Da ps unterbrochen werden kann, ist die Ausgabe nicht unbedingt
korrekt. Die Optionen und die Ausgabe variieren je nach System:
a auch andere Benutzer, nicht nur eigene Prozesse
g auch Prozeßgruppenführer (z.B. login-Shell)
m (NeXT) auch Threads, (Berkeley) Memory
x auch Prozesse ohne Kontroll-Terminal
c nur Kommandoname
e auch Environment
j (Berkeley) joborientiert, also mit Session
l viel Information
s (Berkeley) Signale
u benutzungsorientiert, also mit Zeit- und Speicherverhalten
v (Berkeley) speicherorientiert, also mit Speicherstatistik
w 132 Spalten
ww unlimitiert
6-3

Man kann die Ausgabe auch auf Prozesse oder Benutzer nach Nummern oder Terminal
nach (abgekürztem) Namen einschränken:
next$ ps -tp3
PID TT STAT TIME COMMAND
21203 p3 SW 0:01 -bash (bash)
24551 p3 R 0:00 ps -tp3
next$ ps -ctp3
PID TT STAT TIME COMMAND
21203 p3 SW 0:02 bash
24555 p3 R 0:00 ps
next$ ps -utp3
USER PID %CPU %MEM VSIZE RSIZE TT STAT TIME COMMAND
axel 21203 0.0 1.6 1.84M 512K p3 SW 0:01 -bash (bash)
root 24552 0.0 0.9 1.68M 280K p3 R 0:00 ps -utp3
next$ ps -lwwtp3
F UID PID PPID CP PRI BASE VSIZE RSIZE WCHAN STAT TT TIME COMMAND
c0000201 200 21203 21200 0 10 10 1.84M 512K 0 SW p3 0:02 -bash
(bash)
c0000001 0 24561 21203 0 10 10 1.68M 280K 0 R p3 0:00 ps -
lwwtp3
linux$ ps j
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
157 158 158 158 pp0 189 S N 200 0:00 -bash
158 189 189 158 pp0 189 R N 200 0:00 ps j
linux$ ps s
UID PID SIGNAL BLOCKED IGNORED CATCHED STAT TTY TIME COMMAND
200 158 00000000 00010000 7fffffff 07813efb S N pp0 0:00 -bash
200 194 00000000 00000000 7fffffff 00000000 R N pp0 0:00 ps s
6-4

proc als Dateisystem
Linux liefert sehr viel Information über den Kern und die Prozesse als fiktive Dateien im
Katalog /proc:
linux$ ls /proc
1/ 5/ 81/ 95/ kcore self@
13/ 56/ 83/ 96/ kmsg stat
157/ 6/ 86/ cmdline ksyms sys/
158/ 7/ 88/ cpuinfo loadavg uptime
2/ 70/ 89/ devices meminfo version
245/ 72/ 91/ dma modules
248/ 74/ 92/ filesystems mounts
3/ 76/ 93/ interrupts net/
4/ 78/ 94/ ioports scsi/
linux$ ls -R /proc/self
cmdline environ fd/ mem stat status
cwd@ exe@ maps| root@ statm
/proc/250/fd:
0@ 1@ 2@ 3@
Viele der ‘‘Dateien’’ sind benutzbare symbolische Links, deren fiktive Inhalte sich aus
st_dev und st_ino ableiten:
linux$ ls -ldi /proc/self/cwd
16973829 lrwx------ 1 axel root 64 Jun 3 17:53
/proc/self/cwd -> [0002]:16008
linux$ ls -lLi /proc/self/cwd/cwd
total 24
14412 drwxr-xr-x 4 axel root 1024 Apr 4 10:32 Apps/
40004 drwxr-xr-x 33 axel root 1024 Feb 3 16:11 Library/
14422 drwx------ 18 axel root 1024 Jun 3 09:47 Mailboxes/
...
6-5

Prozeßmanipulationen
Prozeßmanipulationen
int fork (void);
fork() kopiert den aufrufenden Prozeß und liefert im neuen Prozeß 0, im alten Prozeß
die Prozeßnummer des neuen Prozesses.
int execl (const char * path, const char * arg0, ... 0);
int execle (const char * path,const char * arg0, ... 0, const char * envp
[]);
int execlp (const char * file, const char * arg0, ... 0);
int execv (const char * path, char *const argv []);
int execve (const char * path, char *const argv [], const char * envp []);
int execvp (const char * file, char *const argv []);
exec lädt im aufrufenden Prozeß ein neues Programm und übergibt Argumente sowie
das aktuelle oder ein neues Environment. Das Programm wird aus einer Datei gelesen,
die auch über PATH gesucht und dann, falls nötig, von einer Shell interpretiert werden
kann.
exec interpretiert #! path arg am Dateianfang: path wird ausgeführt und path und arg
bilden den Anfang von argv[] für das Programm, der ursprüngliche Vektor folgt
danach.
void _exit (int code);
_exit() beendet den aufrufenden Prozeß ohne aufzuräumen.
int wait (int * status);
wait() blockiert den aufrufenden Prozeß, bis einer seiner mit fork() erzeugten
Abkömmlinge terminiert. *status enthält entweder code

Prozeßzustand
Über fork() und exec hinweg bleiben große Teile des Prozeßzustands erhalten:
ändern fork() exec
getpid() neu
getppid() Erzeuger
getpgrp() setpgrp()
getsid() setsid()
times() alle 0
Kontroll-Terminal setsid()
getuid() setuid()
geteuid() seteuid() neu, falls S_ISUID
S_ISUID chmod()
getgid() setgid()
getegid() setegid() neu, falls S_ISGID
S_ISGID chmod()
Environment kopiert kopiert
getcwd() chdir()
chroot()
umask() umask()
Profiling profil() wird beendet
nice() nice()
shm-Segmente werden abgehängt
semadj-Werte alle 0
File-Deskriptoren gleiche Position gleiche Position
FD_CLOEXEC werden geschlossen
Locks flock() nicht geerbt
Signale signal()
SIG_DFL
SIG_IGN
SIG_HOLD
Funktion SIG_DFL
pending keine
6-7

Prozeßgruppen
Prozeßgruppen gliedern Prozesse zur Verteilung von Signalen und zur Zugehörigkeit zu
einem Kontrollterminal.
Jeder Prozeß gehört zu einer Prozeßgruppe, die einen Anführer haben kann — für ihn
sind Prozeß- und Prozeßgruppennummer gleich.
Jede Prozeßgruppe enthält wenigstens einen Prozeß, der aber nicht unbedingt der
Anführer sein muß.
int getpgrp (void);
liefert die Prozeßgruppennummer des Aufrufers.
int setpgrp (int pid, int pgrp);
setzt für den Prozeß pid (0 bezeichnet den Aufrufer) die Prozeßgruppennummer pgrp
(0 bezeichnet pid als Prozeßgruppe) — das darf ein Prozeß für sich und seine
Abkömmlinge machen, aber für einen Abkömmling nur , wenn er exec noch nicht
ausgeführt hat.
setpgrp() ist so kompliziert definiert, um eine Race-Bedingung zu vermeiden:
setpgrp(pid = fork(), 0);
Im Erzeuger bezeichnet pid den Abkömmling. Der Erzeuger setzt also die
Prozeßgruppe für den Abkömmling auf pid — der Abkömmling erhält seine eigene
Prozeßgruppe.
Im Abkömmling liefert fork() Null und das bezeichnet den Aufrufer, also den
Abkömmling. Auch hier erhält der Abkömmling seine eigene Prozeßgruppe.
Egal wer den Aufruf zuerst ausführt — der Abkömmling wird in jedem Fall zum
Anführer seiner eigenen, neuen Prozeßgruppe.
6-8

Sessions
Sessions gliedern Prozeßgruppen zur Verteilung von Signalen und zur Zugehörigkeit zu
einem Kontroll-Terminal.
Jeder Prozeß gehört zu einer Session.
Jede Session enthält wenigstens eine Prozeßgruppe.
int setsid (void);
Wenn der Aufrufer nicht Anführer einer Prozeßgruppe ist, wird er wird Anführer einer
neuen Prozeßgruppe, die einziges Mitglied einer neuen Session mit der
Prozeßnummer des Aufrufers ist. Der Aufrufer verliert außerdem sein Kontroll-
Terminal, falls er eines hat.
Der Aufrufer kann als Anführer der Session ein Kontroll-Terminal bekommen — je nach
System durch Zugriff auf ein freies Terminal oder durch ioctl() — das dann die
Session kontrolliert.
/dev/tty vertritt immer das Kontroll-Terminal — falls der zugreifende Prozeß eines
besitzt. Es kann aber nicht zum Setzen oder Bestimmen der Terminalgruppe verwendet
werden.
Terminalgruppen
Eine Session kann eine sogenannte Vordergrund-Prozeßgruppe haben, an die das
Kontroll-Terminal seine Signale liefert und die von diesem Terminal lesen oder (stty
tostop) zu diesem Terminal schreiben dürfen. Die anderen Prozeßgruppen bilden den
Hintergrund.
int tcgetpgrp (int fd);
int tcsetpgrp (int fd, int pgrp);
tcgetpgrp() liefert die Nummer der Vordergrund-Prozeßgruppe für das Terminal, mit
dem fd verbunden ist — das kann nicht /dev/tty sein.
tcsetpgrp() setzt für das Kontroll-Terminal, mit dem fd verbunden ist — das kann nicht
/dev/tty sein — pgrp als Vordergrund-Prozeßgruppe, wobei man in der Session von fd
bleiben muß.
6-9

Job-Control
Eine Job-Control-Shell verwaltet jedes Kommando in einer eigenen Prozeßgruppe, die
folglich Hintergrund-Prozeßgruppe ist.
Signale gehen vom Terminal-Treiber nur an die Vordergrund-Prozeßgruppe des Kontroll-
Terminals.
Hintergrund-Prozesse handeln sich Signale ein, wenn sie vom Kontroll-Terminal lesen
oder (stty tostop) dorthin schreiben wollen.
Die Shell läßt sich über den Zustand der Abkömmlinge berichten und schaltet die
Prozeßgruppen jeweils um, damit auch Hintergrundprozesse in den Vordergrund
kommen und vom Terminal lesen können.
Bei Linux kann man die Unterschiede mit ps -j beobachten. Bei NeXT verwendet man
das folgende Programm proc/psj:
#include
#include
int main () {
#if defined _POSIX_SOURCE || defined __FreeBSD__
int tgrp = tcgetpgrp(2);
int pgrp = getpgrp();
if (tgrp < 0)
perror("tcgetpgrp");
#else
# define tgrp -1
int pgrp = getpgrp(0);
#endif
}
fprintf(stderr, "pid %d, ppid %d, pgrp %d, tgrp %d\n",
getpid(), getppid(), pgrp, tgrp);
fflush(stderr);
return 0;
Es liefert folgendes — wenn auch nicht immer:
sh$ psj
pid 25633, ppid 25632, pgrp 25632, tgrp 25632
sh$ psj &
25634
pid 25634, ppid 25632, pgrp 25632, tgrp 25632
csh% psj
pid 25636, ppid 25635, pgrp 25636, tgrp 25636
csh% psj &
[1] 25637
pid 25637, ppid 25635, pgrp 25637, tgrp 25635
bash$ psj
pid 25638, ppid 21203, pgrp 25638, tgrp 25638
bach$ psj &
[1] 25639
6-10

pid 25639, ppid 21203, pgrp 25639, tgrp 21203
Man sieht, wie die Bourne-Shell die Prozeßgruppe unverändert läßt, während die C-
Shell jedem Prozeß eine eigene Gruppe gibt.
Mit psj kann man auch die verschiedenen Modelle untersuchen, nach denenShells
mehrstufige Pipelines aufbauen:
sh$ psj | psj | psj
pid 25649, ppid 25648, pgrp 25648, tgrp 25648
pid 25650, ppid 1, pgrp 25648, tgrp 25648
pid 25651, ppid 1, pgrp 25648, tgrp 25648
sh$ psj | psj | psj &
25652
pid 25652, ppid 25648, pgrp 25648, tgrp 25648
pid 25653, ppid 1, pgrp 25648, tgrp 25648
pid 25654, ppid 1, pgrp 25648, tgrp 25648
csh% psj | psj | psj
pid 25657, ppid 25655, pgrp 25656, tgrp 25656
pid 25658, ppid 25655, pgrp 25656, tgrp 25656
pid 25656, ppid 25655, pgrp 25656, tgrp 25656
csh% psj | psj | psj &
[1] 25659 25660 25661
pid 25661, ppid 25655, pgrp 25659, tgrp 25655
pid 25659, ppid 25655, pgrp 25659, tgrp 25655
pid 25660, ppid 25655, pgrp 25659, tgrp 25655
bash$ psj | psj | psj
pid 25642, ppid 21203, pgrp 25642, tgrp 25642
pid 25644, ppid 21203, pgrp 25642, tgrp 25642
pid 25643, ppid 21203, pgrp 25642, tgrp 25642
bash$ psj | psj | psj &
[1] 25647
pid 25647, ppid 21203, pgrp 25645, tgrp 21203
pid 25645, ppid 21203, pgrp 25645, tgrp 21203
pid 25646, ppid 21203, pgrp 25645, tgrp 21203
Es stellt sich heraus, daß auf NeXT bei einer Posix-konformen Übersetzung die
Ausgabe von einem Hintergrund-Prozeß zum Kontroll-Terminal nicht korrekt bearbeitet
wird:
$ stty tostop; cc -I../include -o psj psj.c; psj &
[1] 11755
[1]+ Stopped (tty output) psj
$ fg
psj
pid 11755, ppid 11607, pgrp 11755, tgrp -1
$ cc -I../include -posix -o psj-posix psj.c; psj-posix &
[1] 11756
$
[1]+ Done psj-posix
6-11

Dämonen
Waisen
Sessions mit Kontroll-Terminal entstehen von init aus für die login-Terminals oder von
inetd aus für Netzverbindungen mit Pseudo-Terminals.
Dämonen wie lpd oder sendmail erhalten dadurch eigene Sessions und isolieren sich
von den Kontroll-Terminals, daß sie verwaist werden:
if (fork() != 0)
wait(...); // Shell wartet auf Kommando...
... // und arbeitet dann weiter
else if (fork() != 0) // Kommando erzeugt Dämon...
exit(0); // ...und endet sofort
else
setsid(); // Dämon ist verwaist...
... // und in eigener Session
Damit passiert dem Dämon nichts mehr , wenn zum Beispiel die login-Shell beendet
wird.
Erzeuger müssen Abkömmlinge mit wait() abschöpfen, damit die Prozeßtabelle nicht
durch Aufbewahren der exit-Codes abgelaufener Prozesse schließlich überläuft.
Wird ein Erzeuger vorzeitig beendet, erbt init (Prozeß 1) seine Abkömmlinge. init führt
praktisch nur wait() aus und reinigt folglich die Prozeßtabelle. Endet init, terminieren
manche UNIX-Kerne selbständig.
Wenn ein Prozeß verwaist, der wegen Zugriff zum Kontroll-Terminal gestoppt ist, kann
er in einer verwaisten Prozeßgruppe sein.
Eine verwaiste Prozeßgruppe hat nur Prozesse, deren Erzeuger in der gleichen Gruppe
oder in einer anderen Session sind — sie können folglich einen gestoppten Prozeß
nicht mehr in den Vordergrund bringen, damit er zum Terminal kommt.
Jeder Prozeß der verwaisten Gruppe erhält ein SIGHUP und ein SIGCONT — dadurch wird
er entweder vernichtet oder fortgesetzt. Greift er dann weiter auf das T erminal zu, wird
dann der Zugriff mit einem Fehler und nicht mehr mit Abstoppen quittiert.
Von Stevens stammt die Idee zum Programm orphan, mit dem man zeigen kann, was
passiert.
6-12

* based on Stevens */
#include
#include
#include
static void trap (int sig) {
printf("[%d]\treceived signal %d\n", getpid(), sig);
fflush(stdout);
}
static void info (const char * who) {
printf("%s\tpid %d, ppid %d, pgrp %d, tgrp %d\n",
who, getpid(), getppid(), getpgrp(), tcgetpgrp(2));
fflush(stdout);
}
int main () {
char ch;
}
info("parent");
switch (fork()) {
case -1: /* error */
perror("fork"), exit(1);
default: /* parent */
sleep(5); /* time for child to stop */
break;
case 0: /* child */
info("child");
signal(SIGHUP, trap); /* catch HUP */
kill(getpid(), SIGTSTP); /* stop for terminal input */
info("cont’d");
if (read(0, &ch, 1) == -1) /* try to read */
perror("read");
}
return 0;
orphan verwaist seinen Abkömmling, der damit eine verwaiste Prozeßgruppe
bevölkert, wenn er von einer Job-Control-Shell gestartet wird. Bei Linux 1.3.88 oder
FreeBSD beobachtet man folgendes korrekte Vorhalten:
linux$ orphan
parent pid 865, ppid 857, pgrp 857, tgrp 857
child pid 866, ppid 865, pgrp 857, tgrp 857
[866] received signal 1
cont’d pid 866, ppid 1, pgrp 857, tgrp 158
read: I/O error
linux$ orphan &
[1] 867
parent pid 867, ppid 158, pgrp 867, tgrp 158
child pid 868, ppid 867, pgrp 867, tgrp 158
[868] received signal 1
cont’d pid 868, ppid 1, pgrp 867, tgrp 158
read: I/O erro
Man sieht auch, daß orphan in eine Hintergrund-Prozeßgruppe wechselt. Bei Linux
1.2.13 klappt es nicht und auch bei NeXT funktioniert es trotz -posix nicht ganz:
6-13

next$ orphan
parent pid 25553, ppid 21203, pgrp 25553, tgrp -1
child pid 25554, ppid 25553, pgrp 25553, tgrp -1
[25554] received signal 1
cont’d pid 25554, ppid 1, pgrp 25553, tgrp -1
next$ echo $?
0
6-14

Signale
Signale
Signale sind asynchron eintretende Ereignisse, die meistens den normalen Ablauf
eines Programms unterbrechen und häufig zum Abbruch des Programms führen. Sie
sind kein guter Mechanismus zur Prozeßkommunikation.
Signale können absichtlich durch kill() oder killpg() an andere oder auch den
gleichen Prozeß verschickt werden, oder sie werden vom System erzeugt. Fast alle
Signale können ignoriert oder mit einer Funktion abgefangen werden.
Bei System V bleibt eine Funktion bei Eintreffen des Signals weiter eingestellt, bei
Berkeley früher und bei Linux nicht. Durch ein Signal unterbrochene Systemaufrufe
werden oft implizit wiederholt, oder man erhält errno == EINTR.
Einfache Signal-Operationen
int kill(int pid, int sig);
int killpg(int pgrp, int sig);
kill() und killpg() schicken das Signal sig an einen Prozeß (pid > 0), an die eigene
Prozeßgruppe (pid == 0 oder pgrp == 0), an eine andere Prozeßgruppe (pid < -1
oder pgrp > 0), an alle eigenen Prozesse (pid == -1) oder an alle nicht zum System
gehörenden Prozesse (pid == -1 für den Super-User). SIGCONT darf immer geschickt
werden, alle anderen Signale nur an eigene Prozesse oder durch den Super-User.
long alarm(long seconds);
alarm() sorgt dafür, daß seconds später SIGALRM an den Aufrufer geschickt wird. Das
Resultat ist das vorher verbleibende Intervall.
int setitimer(int which, const struct itimerval *value, struct itimerval
*ovalue);
int getitimer(int which, struct itimerval *value);
Mit diesen Funktionen können das Echtzeit-Signal (ITIMER_REAL, SIGALRM), das User-
CPU-Zeit-Signal (ITIMER_VIRT, SIGVTALRM) und das profiling-Signal (ITIMER_PROF,
SIGPROF) in Mikrosekunden auf einem Raster (10 ms) kontrolliert werden.
int pause(void);
Der Prozeß wartet auf ein Signal. pause() liefert immer -1.
int (*signal (int sig, void (*func)(int)))(int);
typedef void (*sighandler_t)(int);
sighandler_t signal(int sig, sighandler_t h);
Diese vereinfachte Schnittstelle vereinbart die Reaktion auf ein Signal sig: Ignorieren
(SIG_INT), Voreinstellung (SIG_DFL) oder Abfangen per Funktion h, die dann die Signal-
Nummer als Argument erhält. signal() liefert die vorherige Einstellung; typisch ist:
6-15

if ((alt = signal(sig, SIG_IGN)) != SIG_IGN)
signal(sig, neu);
So vermeidet man, ein ignoriertes Signal zu reaktivieren.
Signal-Namen und -Nummern
Signale werden durch Namen oder Nummern bezeichnet, die man zum Beispiel durch
kill -l als eingebautes Kommando von bash erfahren kann:
$ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGIOT 7) SIGEMT 8) SIGFPE
9) SIGKILL 10) SIGBUS 11) SIGSEGV 12) SIGSYS
13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGURG
17) SIGSTOP 18) SIGTSTP 19) SIGCONT 20) SIGCHLD
21) SIGTTIN 22) SIGTTOU 23) SIGIO 24) SIGXCPU
25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH
29) SIGLOST 30) SIGUSR1 31) SIGUSR2
Nicht alle Namen — und insbesondere ihre Bindungen an spezielle Nummern — sind
portabel. Die folgende Liste ist aus NeXT, Linux und Stevens kombiniert.
6-16

Kontroll-Terminal SIGHUP A Verwaisen eines Prozesses, Aufhängen
einer Modem-Verbindung
SIGINT A Unterbrechung (control-C o.ä.)
SIGQUIT C Abbruch mit core (control-\ o.ä.)
SIGTSTP S Stop (control-Z o.ä.)
SIGTTIN S Eingabe in Hintergrund-Prozeßgruppe
SIGTTOU S Ausgabe in Hintergrund-Prozeßgruppe
Fehlverhalten SIGILL C illegaler Maschinenbefehl
SIGTRAP C* trace oder breakpoint
SIGEMT C* EMT-Befehl
SIGIOT C* IOT-Befehl
SIGABRT C abort()
SIGFPE C Gleitkomma-Fehler
SIGBUS C* illegale Adresse (nicht bei Linux)
SIGSEGV C illegale Adresse
SIGSYS C* falscher Systemaufruf (nicht bei Linux)
SIGSTKFLT A* (Linux) Coprozessor-Fehler
SIGPWR I* (System V) Power-Fail und -Restart
Kommunikation SIGPIPE A Schreiben ohne Leser (Pipe, Socket)
SIGURG I* out-of-band Daten an Socket
SIGIO I* asynchrones I/O ist möglich
SIGPOLL A* (System V) poll()
SIGWINCH I* Änderung der Fenstergröße
Zeit SIGALRM A alarm()
SIGVTALRM A* virtuelle Zeitscheibe, setitimer()
SIGPROF A* profiling Zeitscheibe, setitimer()
Prozeßkontrolle SIGKILL AU unbedingter Abbruch
SIGTERM A bedingter Abbruch
SIGSTOP SU unbedingtes Anhalten
SIGCONT I fortsetzen wenn angehalten
SIGCHLD I Abkömmling ändert Zustand
Ressourcen SIGXCPU A* Zeitüberschreitung, setrlimit()
SIGXFSZ A* Dateigrößenüberschreitung,
setrlimit()
frei definierbar SIGUSR1 A
SIGUSR2 A
6-17

Dabei bedeuten:
A Voreinstellung ist Abbruch des Prozesses.
C Voreinstellung ist Abbruch plus core-Dump.
I Voreinstellung ist Ignorieren des Signals.
S Voreinstellung ist Stoppen des Prozesses.
U SIGKILL und SIGSTOP können nicht abgefangen oder ignoriert werden
* gibt’s nicht in Posix
6-18

Prozeßkommunikation
Themen
• Pipes
• Named Pipes
• Messages
• Semaphore
• Shared Memory
1996/5/20
1996/5/20