|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+# Homework hw7 t2
|
|
|
2
|
+
|
|
|
3
|
+- [Migration der Shell in ein Library
|
|
|
4
|
+ Projekt](#migration-der-shell-in-ein-library-projekt)
|
|
|
5
|
+- [Eigener Fehler Typ](#eigener-fehler-typ)
|
|
|
6
|
+- [Neue Commands](#neue-commands)
|
|
|
7
|
+ - [execv](#execv)
|
|
|
8
|
+ - [pipe](#pipe)
|
|
|
9
|
+- [Kommentare und Tests](#kommentare-und-tests)
|
|
|
10
|
+- [Externe Crates](#externe-crates)
|
|
|
11
|
+
|
|
|
12
|
+## Migration der Shell in ein Library Projekt
|
|
|
13
|
+
|
|
|
14
|
+Legen Sie ein Library Projekt an mit einer zusätzlichen `main.rs` Datei. Wandeln
|
|
|
15
|
+Sie Ihre Shell Lösung aus hw6 in ein Library Projekt, welche mittels cargo run
|
|
|
16
|
+die Shell - wie bisher - im interaktiven Modus startet.
|
|
|
17
|
+
|
|
|
18
|
+Verschieben Sie Ihre Tests der Library nach `tests/task2.rs`.
|
|
|
19
|
+
|
|
|
20
|
+## Eigener Fehler Typ
|
|
|
21
|
+
|
|
|
22
|
+Definieren Sie einen eigenen Fehler Typen, den Sie in Ihren Funktionen benutzen.
|
|
|
23
|
+Definieren Sie den `ShellError` und die zugehörigen Traits im Modul
|
|
|
24
|
+`shellerror.rs`. Der eigene Fehler soll in allen Ihren Funktionen verwendet
|
|
|
25
|
+werden, die einen Fehlertypen zurück geben.
|
|
|
26
|
+
|
|
|
27
|
+## Neue Commands
|
|
|
28
|
+
|
|
|
29
|
+### execv
|
|
|
30
|
+
|
|
|
31
|
+Die Eingabe wird als Aufruf eines Programms, inkl. Parameter, ausgewertet und es
|
|
|
32
|
+wird versucht, das zugehörige Programm zu starten (mit *execvp()*). Wird das
|
|
|
33
|
+Programm nicht gefunden, so wird eine Fehlermeldung ausgegeben.
|
|
|
34
|
+
|
|
|
35
|
+```text
|
|
|
36
|
+bsys-shell /Users/maechtel$ ps 1
|
|
|
37
|
+ PID TT STAT TIME COMMAND
|
|
|
38
|
+ 1 ?? Ss 28:42.16 /sbin/launchd
|
|
|
39
|
+bsys-shell /Users/maechtel$ cat blabla.txt
|
|
|
40
|
+cat: blabla.txt: No such file or directory
|
|
|
41
|
+bsys-shell /Users/maechtel$ cat testdatei.txt
|
|
|
42
|
+Hello you snoopy user ....
|
|
|
43
|
+bsys-shell /Users/maechtel$ file testdatei.txt
|
|
|
44
|
+testdatei.txt: ASCII text
|
|
|
45
|
+bsys-shell /Users/maechtel$ exit
|
|
|
46
|
+exit
|
|
|
47
|
+```
|
|
|
48
|
+
|
|
|
49
|
+### pipe
|
|
|
50
|
+
|
|
|
51
|
+Die Pipe (**|**) ist hier als Command angegeben, da sie eine neue Art des
|
|
|
52
|
+Programmaufrufs implementiert. Beachten Sie dazu auch die Informationen aus der
|
|
|
53
|
+Vorlesung, insbesondere die Reihenfolge, wie die Kommandos rechts und links der
|
|
|
54
|
+jeweiligen Pipe aufzurufen sind. Scannen Sie somit die Eingabe nach Pipes und
|
|
|
55
|
+teilen Sie den String entsprechend in Substrings auf. Die Substrings entsprechen
|
|
|
56
|
+den einzelnen Programmen, die miteinander per Pipe verbunden werden. Es genügt,
|
|
|
57
|
+wenn 2 Programme per Pipe verbunden werden. Eingaben wie **cat filename.txt |
|
|
|
58
|
+grep grading | sort**, also mehr als eine Pipe, müssen nicht interpretiert und
|
|
|
59
|
+implementiert werden.
|
|
|
60
|
+
|
|
|
61
|
+## Kommentare und Tests
|
|
|
62
|
+
|
|
|
63
|
+Kommentieren Sie Ihre Funktionen und schreiben Sie eigene Integration Tests in
|
|
|
64
|
+tests/ soweit möglich. Die Dokumentation soll sich per **cargo doc** erstellen
|
|
|
65
|
+lassen.
|
|
|
66
|
+
|
|
|
67
|
+Einfache Tests (manchmal sagt ein Test zu einer Funktion mehr als viele
|
|
|
68
|
+Kommentarzeilen ...) können auch direkt in die Dokumentation 'codiert' werden,
|
|
|
69
|
+siehe [Documentation Tests][]
|
|
|
70
|
+
|
|
|
71
|
+## Externe Crates
|
|
|
72
|
+
|
|
|
73
|
+Benutzen Sie für Ihre Implementierung nur die externe Crate `nix`.
|
|
|
74
|
+
|
|
|
75
|
+
|
|
|
76
|
+
|
|
|
77
|
+[Documentation Tests]:
|
|
|
78
|
+https://doc.rust-lang.org/book/testing.html#documentation-tests
|