Update master from bsys-ws17-template/hw6

files/hw6.txt

@@ -0,0 +1,19 @@
+./hw6/README.md
+
+./hw6/task1/Cargo.lock
+./hw6/task1/Cargo.toml
+./hw6/task1/src/main.rs
+./hw6/task1/tests/output.bats
+
+./hw6/task2/Cargo.lock
+./hw6/task2/Cargo.toml
+./hw6/task2/src/main.rs
+./hw6/task2/src/shell.rs
+./hw6/task2/src/command.rs
+./hw6/task2/src/unit_tests_shell.rs
+
+./hw6/simu1/ANSWERS.md
+./hw6/simu1/QUESTIONS.md
+./hw6/simu1/README-lottery.md
+./hw6/simu1/lottery.py
+

hw6/README.md

@@ -0,0 +1,27 @@
+# hw6
+
+## Tasks
+
+To fulfill **hw6** you have to solve:
+
+- task1
+- task2
+- simu1
+
+## Files
+
+You find already or reuse some files for rust tasks. Please remember to use cargo to create a new project for each task and copy the given files into their dedicated directories.
+
+## Pull-Request
+
+Please merge any accepted reviews into your branch. If you are ready with the homework, all tests run, please create a pull request named **hw6**.
+
+## Credits for hw6
+
+| Task     | max. Credits | Comment |
+| -------- | ------------ | ------- |
+| task1    | 1            |         |
+| task2    | 2            |         |
+| simu1    | 1            |         |
+| Deadline | +1           |         |
+| =        | 5            |         |

hw6/simu1/QUESTIONS.md

@@ -0,0 +1,26 @@
+# QUESTIONS: 9-Scheduling-Lottery
+
+This program, **lottery.py**, allows you to see how a lottery scheduler works.
+See the README for details.
+
+## Warmup
+
+1. Compute the solutions for simulations with 3 jobs and random seeds of 1, 2,
+   and 3.
+
+## Questions
+
+1. Now run with two specific jobs: each of length 10, but one (job 0) with just
+   1 ticket and the other (job 1) with 100 (e.g., `-l 10:1,10:100`). 
+   - What happens when the number of tickets is so imbalanced? 
+   - Will job 0 ever run before job 1 completes? How often? 
+   - In general, what does such a ticket imbalance do to the behavior of lottery
+     scheduling?
+1. When running with two jobs of length 100 and equal ticket allocations of 100
+   (`-l 100:100,100:100`), how unfair is the scheduler? Run with some different
+   random seeds to determine the (probabilistic) answer; let unfairness be
+   determined by how much earlier one job finishes than the other.
+1. How does your answer to the previous question change as the quantum size
+   (`-q`) gets larger?
+1. Can you make a version of the graph that is found in the chapter? What else
+   would be worth exploring? How would the graph look with a stride scheduler?

hw6/simu1/README-lottery.md

@@ -0,0 +1,126 @@
+# README Scheduler: Lottery
+
+This program, lottery.py, allows you to see how a lottery scheduler works. As
+always, there are two steps to running the program. First, run without the -c
+flag: this shows you what problem to solve without revealing the answers. 
+
+```text
+prompt> ./lottery.py -j 2 -s 0
+...
+Here is the job list, with the run time of each job: 
+  Job 0 ( length = 8, tickets = 75 )
+  Job 1 ( length = 4, tickets = 25 )
+
+Here is the set of random numbers you will need (at most):
+Random 511275
+Random 404934
+Random 783799
+Random 303313
+Random 476597
+Random 583382
+Random 908113
+Random 504687
+Random 281838
+Random 755804
+Random 618369
+Random 250506
+```
+
+When you run the simulator in this manner, it first assigns you some random jobs
+(here of lengths 8, and 4), each with some number of tickets (here 75 and 25,
+respectively). The simulator also gives you a list of random numbers, which you
+will need to determine what the lottery scheduler will do. The random numbers
+are chosen to be between 0 and a large number; thus, you'll have to use the
+modulo operator to compute the lottery winner (i.e., winner should equal this
+random number modulo the total number of tickets in the system). 
+
+Running with -c shows exactly what you are supposed to calculate:
+
+```text
+prompt> ./lottery.py -j 2 -s 0 -c
+...
+** Solutions **
+Random 511275 -> Winning ticket 75 (of 100) -> Run 1
+  Jobs:  (  job:0 timeleft:8 tix:75 ) (* job:1 timeleft:4 tix:25 )
+Random 404934 -> Winning ticket 34 (of 100) -> Run 0
+  Jobs:  (* job:0 timeleft:8 tix:75 ) (  job:1 timeleft:3 tix:25 )
+Random 783799 -> Winning ticket 99 (of 100) -> Run 1
+  Jobs:  (  job:0 timeleft:7 tix:75 ) (* job:1 timeleft:3 tix:25 )
+Random 303313 -> Winning ticket 13 (of 100) -> Run 0
+  Jobs:  (* job:0 timeleft:7 tix:75 ) (  job:1 timeleft:2 tix:25 )
+Random 476597 -> Winning ticket 97 (of 100) -> Run 1
+  Jobs:  (  job:0 timeleft:6 tix:75 ) (* job:1 timeleft:2 tix:25 )
+Random 583382 -> Winning ticket 82 (of 100) -> Run 1
+  Jobs:  (  job:0 timeleft:6 tix:75 ) (* job:1 timeleft:1 tix:25 )
+--> JOB 1 DONE at time 6
+Random 908113 -> Winning ticket 13 (of 75) -> Run 0
+  Jobs:  (* job:0 timeleft:6 tix:75 ) (  job:1 timeleft:0 tix:--- )
+Random 504687 -> Winning ticket 12 (of 75) -> Run 0
+  Jobs:  (* job:0 timeleft:5 tix:75 ) (  job:1 timeleft:0 tix:--- )
+Random 281838 -> Winning ticket 63 (of 75) -> Run 0
+  Jobs:  (* job:0 timeleft:4 tix:75 ) (  job:1 timeleft:0 tix:--- )
+Random 755804 -> Winning ticket 29 (of 75) -> Run 0
+  Jobs:  (* job:0 timeleft:3 tix:75 ) (  job:1 timeleft:0 tix:--- )
+Random 618369 -> Winning ticket 69 (of 75) -> Run 0
+  Jobs:  (* job:0 timeleft:2 tix:75 ) (  job:1 timeleft:0 tix:--- )
+Random 250506 -> Winning ticket 6 (of 75) -> Run 0
+  Jobs:  (* job:0 timeleft:1 tix:75 ) (  job:1 timeleft:0 tix:--- )
+--> JOB 0 DONE at time 12
+```
+
+As you can see from this trace, what you are supposed to do is use the random
+number to figure out which ticket is the winner. Then, given the winning ticket,
+figure out which job should run. Repeat this until all of the jobs are finished
+running. It's as simple as that -- you are just emulating what the lottery
+scheduler does, but by hand!
+
+Just to make this absolutely clear, let's look at the first decision made in the
+example above. At this point, we have two jobs (job 0 which has a runtime of 8
+and 75 tickets, and job 1 which has a runtime of 4 and 25 tickets). The first
+random number we are given is 511275. As there are 100 tickets in the system,
+511275 \% 100 is 75, and thus 75 is our winning ticket.
+
+If ticket 75 is the winner, we simply search through the job list until we find
+it. The first entry, for job 0, has 75 tickets (0 through 74), and thus does not
+win; the next entry is for job 1, and thus we have found our winner, so we run
+job 1 for the quantum length (1 in this example). All of this is shown in the
+print out as follows:
+
+```text
+Random 511275 -> Winning ticket 75 (of 100) -> Run 1
+  Jobs:  (  job:0 timeleft:8 tix:75 ) (* job:1 timeleft:4 tix:25 )
+```
+
+As you can see, the first line summarizes what happens, and the second simply
+shows the entire job queue, with an * denoting which job was chosen.
+
+The simulator has a few other options, most of which should be self-explanatory.
+Most notably, the -l/--jlist flag can be used to specify an exact set of jobs
+and their ticket values, instead of always using randomly-generated job lists.
+
+```text
+prompt> ./lottery.py -h
+Usage: lottery.py [options]
+
+Options:
+  -h, --help            
+      show this help message and exit
+  -s SEED, --seed=SEED  
+      the random seed
+  -j JOBS, --jobs=JOBS  
+      number of jobs in the system
+  -l JLIST, --jlist=JLIST
+      instead of random jobs, provide a comma-separated list
+      of run times and ticket values (e.g., 10:100,20:100
+      would have two jobs with run-times of 10 and 20, each
+      with 100 tickets)
+  -m MAXLEN, --maxlen=MAXLEN
+      max length of job
+  -T MAXTICKET, --maxtick=MAXTICKET
+      maximum ticket value, if randomly assigned
+  -q QUANTUM, --quantum=QUANTUM
+      length of time slice
+  -c, --compute
+      compute answers for me
+
+```

hw6/simu1/lottery.py

@@ -0,0 +1,119 @@
+#! /usr/bin/env python
+
+import sys
+from optparse import OptionParser
+import random
+
+parser = OptionParser()
+parser.add_option('-s', '--seed', default=0, help='the random seed',              action='store', type='int', dest='seed')
+parser.add_option('-j', '--jobs', default=3, help='number of jobs in the system', action='store', type='int', dest='jobs')
+parser.add_option('-l', '--jlist', default='', help='instead of random jobs, provide a comma-separated list of run times and ticket values (e.g., 10:100,20:100 would have two jobs with run-times of 10 and 20, each with 100 tickets)',  action='store', type='string', dest='jlist')
+parser.add_option('-m', '--maxlen',  default=10,  help='max length of job',         action='store', type='int', dest='maxlen')
+parser.add_option('-T', '--maxticket', default=100, help='maximum ticket value, if randomly assigned',          action='store', type='int', dest='maxticket')
+parser.add_option('-q', '--quantum', default=1,   help='length of time slice', action='store', type='int', dest='quantum')
+parser.add_option('-c', '--compute', help='compute answers for me', action='store_true', default=False, dest='solve')
+
+(options, args) = parser.parse_args()
+
+random.seed(options.seed)
+
+print 'ARG jlist', options.jlist
+print 'ARG jobs', options.jobs
+print 'ARG maxlen', options.maxlen
+print 'ARG maxticket', options.maxticket
+print 'ARG quantum', options.quantum
+print 'ARG seed', options.seed
+print ''
+
+print 'Here is the job list, with the run time of each job: '
+
+import operator
+
+
+tickTotal = 0
+runTotal  = 0
+joblist = []
+if options.jlist == '':
+    for jobnum in range(0,options.jobs):
+        runtime = int(options.maxlen * random.random())
+        tickets = int(options.maxticket * random.random())
+        runTotal += runtime
+        tickTotal += tickets
+        joblist.append([jobnum, runtime, tickets])
+        print '  Job %d ( length = %d, tickets = %d )' % (jobnum, runtime, tickets)
+else:
+    jobnum = 0
+    for entry in options.jlist.split(','):
+        (runtime, tickets) = entry.split(':')
+        joblist.append([jobnum, int(runtime), int(tickets)])
+        runTotal += int(runtime)
+        tickTotal += int(tickets)
+        jobnum += 1
+    for job in joblist:
+        print '  Job %d ( length = %d, tickets = %d )' % (job[0], job[1], job[2])
+print '\n'
+
+if options.solve == False:
+    print 'Here is the set of random numbers you will need (at most):'
+    for i in range(runTotal):
+        r = int(random.random() * 1000001)
+        print 'Random', r
+
+if options.solve == True:
+    print '** Solutions **\n'
+
+    jobs  = len(joblist)
+    clock = 0
+    for i in range(runTotal):
+        r = int(random.random() * 1000001)
+        winner = int(r % tickTotal)
+
+        current = 0
+        for (job, runtime, tickets) in joblist:
+            current += tickets
+            if current > winner:
+                (wjob, wrun, wtix) = (job, runtime, tickets)
+                break
+
+        print 'Random', r, '-> Winning ticket %d (of %d) -> Run %d' % (winner, tickTotal, wjob)
+        # print 'Winning ticket %d (of %d) -> Run %d' % (winner, tickTotal, wjob)
+
+        print '  Jobs:',
+        for (job, runtime, tickets) in joblist:
+            if wjob == job:
+                wstr = '*'
+            else:
+                wstr = ' '
+
+            if runtime > 0:
+                tstr = tickets
+            else:
+                tstr = '---'
+            print ' (%s job:%d timeleft:%d tix:%s ) ' % (wstr, job, runtime, tstr), 
+        print ''
+
+        # now do the accounting
+        if wrun >= options.quantum:
+            wrun -= options.quantum
+        else:
+            wrun = 0
+
+        clock += options.quantum
+
+        # job completed!
+        if wrun == 0:
+            print '--> JOB %d DONE at time %d' % (wjob, clock)
+            tickTotal -= wtix
+            wtix = 0
+            jobs -= 1
+
+        # update job list
+        joblist[wjob] = (wjob, wrun, wtix)
+
+        if jobs == 0:
+            print ''
+            break
+
+
+
+

hw6/task1/README.md

@@ -0,0 +1,72 @@
+# README hw6-t1
+
+Schreiben Sie ein Programm, welches 2 Child's erzeugt. Der Parent übergibt an die beiden Childs über eine Pipe die Daten als Strings, die als Parameter beim Aufruf mit angegeben werden.
+
+Bei Aufruf des Programms geben Sie eine Zahlensequenz (`i32`) von mindestens 2 Zahlen an. Diese Zahlensequenz übergibt dann der Parent an die beiden Childs. Die Zahlen sind alle vom Typ `i32`.
+
+Werden zuwenig Parameter angegeben, so soll eine(!) Zeile 'Hilfe' ausgegeben werden, wie z.B.:
+
+```text
+Correct usage: number number <number> ...
+```
+
+> Wichtig: Nur eine Zeile 'Hilfe' ausgeben.
+
+Child1 berechnet aus der Zahlensequenz die Summe, Child2 das Produkt. Child1 und Child2 geben dann das Ergebnis auf der Konsole direkt aus.
+
+```text
+$ ./task1 -1 2 4 6 19 -100
+sending to childs: -1 2 4 6 19 -100
+Sum = -70
+Mul = 91200
+```
+
+> Format der Ausgabe genau einhalten. Das bedeutet, die Ausgabe des Childs mit der Summenberechnung muss immer VOR der Ausgabe des Childs mit der Multiplikation erfolgen. Welchen einfachen, allerdings Laufzeit 'schädlichen' Trick können Sie dafür benutzen, den Sie bereits kennen? Wie lässt sich der Parameter dafür tunen, um eine optimale Laufzeit (kurz!) des Programms zu erreichen. Kennen Sie eine Möglichkeit, ohne diesen Trick eine eindeutige Reihenfolge der Childs vorzugeben (muss nicht implementiert werden)?
+
+Werten Sie den Status der Childs im Elternprozess aus und beenden Sie das Programm nur im Erfolgsfall beider Childs mit dem Exit-Code 0. Erfolgsfall bedeutet dabei, dass der Child beendet wurde und den Exit Code 0 gesendet hat. Treten Fehler im Child auf, so sendet der Child z.B. den exit Code 1, so dass der Elternprozess dies auswerten kann und das Programm (Parent) ebenfalls mit exit Code 1 beendet.
+
+>Tip: waitpid() sollte dazu entsprechend ausgewertet werden.
+
+Beim Aufruf über cargo die '--' nicht vergessen, siehe dazu  **cargo help run**.
+
+Die Daten zwischen Eltern und Kindern werden als Byte-Stream gesendet. Achten Sie auf die Größe des Puffers, den die Childs zum Empfangen anlegen. Definieren Sie für diese Größe eine `const` und setzen Sie diese auf 256.
+
+Da die eingelesenen Argumente bereits als Strings vorliegen, bietet es sich an im Programm intern mit Strings zu arbeiten. Damit ergeben sich folgende Hilfsfunktionen:
+
+- `concatenate_strings()` :
+- `split_into_strings()`:
+- `sum_strings()`:
+- `mul_strings()`:
+
+> Achten Sie auf einen geeignet grossen Rückgabewert im Erfolgsfall, insbesondere in der Funktion, die die Multiplikation ausführt (`mul_strings()`).
+
+> Achten Sie aber bei Ihren Berechnungen auch darauf, das kein Overflow auftreten kann, der das Programm abbricht (siehe Rust Standarddoku: `overflowing`). Wenn einen Berechnung aufgrund eines auftretenden Overflows nicht durchgeführt werden kann, so gibt der Child einen Fehler aus und terminiert - wie immer im Fehlerfall -  mit dem Exitcode '1'. Die Ausgabe des Programms könnte dann z.B. folgendermassen aussehen:
+
+```text
+> cargo run -- 1000 1000 1000 1000 1000 1000 1000
+...
+Sum = 7000
+... Overflow would happen in mul_strings()
+...
+```
+
+> ... steht für mögliche andere Ausgaben
+
+Darüber hinaus sollten Sie bei Code-Wiederholungen prinzipiell immer überlegen, welche weiteren Hilfsfunktionen sich dadurch anbieten.
+
+## Externe Crates
+
+Benutzen Sie für Ihre Implementierung nur die externe Crate `nix`.
+
+## Module und Tests
+
+Ob und wie Sie den Code in Module aufteilen wollen ist Ihnen überlassen. Schreiben Sie jedoch Ihre Unit-Tests in der Datei `unit_test_pipe.rs` oder als eigenständigen Test, der von 'cargo test' aufgerufen wird, siehe auch [Testing][]. Einfache Tests können auch direkt in die Dokumentation 'codiert' werden, siehe [Documentation Tests][]
+
+Achten Sie beim Exit Code des Elternprozesses darauf, dass dieser nur 0 ist, wenn BEIDE Childs jeweils einen exit Code 0 zurücksenden.
+
+## Dokumentation
+
+Es ist ausreichend, wenn Sie Ihre Dokumentation im Code soweit ergänzen, dass dieser nachvollziehbar ist. Eine Dokumentation über `cargo doc` muss nicht erstellt werden.
+
+[Testing]: https://doc.rust-lang.org/book/testing.html
+[Documentation Tests]: https://doc.rust-lang.org/book/testing.html#documentation-tests

hw6/task1/tests/output.bats

@@ -0,0 +1,72 @@
+#!/usr/bin/env bats
+
+
+@test "task1: Check that we have a debug output" {
+    run stat "$BATS_TEST_DIRNAME/../target/debug/task1"
+    [ "$status" -eq 0 ]
+}
+
+# Check lines of output
+
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with to no paras must be exact 1 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 1 | wc -l | xargs"
+    [ "$output" = "1" ]
+
+}
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with one para must be exact 1 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' -1 | wc -l | xargs"
+    [ "$output" = "1" ]
+
+}
+
+
+# wc output with white spaces is trimmed by xargs
+@test "task1: Output with correct para must be exact 3 line long" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 2 3 4 5 6 7 8 9 | wc -l | xargs"
+    [ "$output" = "3" ]
+}
+
+
+# Check results
+
+@test "task1: 1 -2 3 -4 5" {
+    run "$BATS_TEST_DIRNAME/../target/debug/task1" 1 -2 3 -4 5
+    [[ "${lines[0]}" =~ "sending to childs: 1 -2 3 -4 5" ]]
+    [[ "${lines[1]}" =~ "Sum = 3" ]]
+    [[ "${lines[2]}" =~ "Mul = 120" ]]
+}
+
+@test "task1: 1 -2 3 -4 5 100 -400 5332 3290 -22 -4646 -1 -1" {
+    run "$BATS_TEST_DIRNAME/../target/debug/task1" 1 -2 3 -4 5 100 -400 5332 3290 -22 -4646 -1 -1
+    [[ "${lines[0]}" =~ "sending to childs: 1 -2 3 -4 5 100 -400 5332 3290 -22 -4646 -1 -1" ]]
+    [[ "${lines[1]}" =~ "Sum = 3655" ]]
+    [[ "${lines[2]}" =~ "Mul = -8606551312128000000" ]]
+}
+
+@test "task1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20" {
+    run "$BATS_TEST_DIRNAME/../target/debug/task1" 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
+    [[ "${lines[0]}" =~ "sending to childs: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20" ]]
+    [[ "${lines[1]}" =~ "Sum = 210" ]]
+    [[ "${lines[2]}" =~ "Mul = 2432902008176640000" ]]
+}
+
+# Status checks
+@test "task1: Output with wrong args (1) does not crash" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' a b c "
+    [ "$status" = 1 ]
+}
+
+# Status checks
+@test "task1: Output with wrong args (2) does not crash" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 1 - 2 "
+    [ "$status" = 1 ]
+}
+
+@test "task1: Overflow Output does not crash" {
+    run bash -c "'$BATS_TEST_DIRNAME/../target/debug/task1' 10000 10000 10000 10000 10000"
+    [ "$status" = 1 ]
+}

hw6/task2/README.md

@@ -0,0 +1,177 @@
+# README hw6-t2
+- [Einleitung](#einleitung)
+- [Implementierung](#implementierung)
+    - [*Shell* Datenstruktur](#shell-datenstruktur)
+        - [Public Methode *new()*](#public-methode-new)
+        - [Public Methode *start() -> Result*](#public-methode-start---result)
+        - [Private Methode *shell_loop() -> Result*](#private-methode-shellloop---result)
+        - [Private Methode *prompt() -> Result<Option<String>, ...>*](#private-methode-prompt---resultoptionstring)
+        - [Private Methode *run()*](#private-methode-run)
+    - ['Command Datenstruktur'](#command-datenstruktur)
+- [Externe Crates](#externe-crates)
+- [Module und Tests](#module-und-tests)
+- [Dokumentation](#dokumentation)
+
+## Einleitung
+
+In dieser Aufgabe werden Sie beginnen, eine einfache, aber robuste Shell zu erstellen. In den nächsten Aufgaben werden Sie diese Shell dann weiter ausbauen.
+
+Dafür werden zu Beginn 2 Objekte (Structs) benötigt:
+
+- Shell
+- Command
+
+Die Unit Tests dieser Objekte schreiben Sie bitte wieder in eigene Dateien, siehe folgendes Diagramm:
+
+![Module](png/shell_module.png)
+
+Die Methoden der Datenstruktur Shell beinhalten das Setup und die Loop einer Shell. In der Loop wird der Prompt ausgegeben und auf die Eingaben des Benutzers gewartet. Schließt der Benutzer seine Eingabe mit RETURN ab, so wertet eine Methode die Eingabezeile aus und erstellt daraus die vom Benutzer eingegeben Kommandos. Diese Loop kann der Benutzer mit dem Kommando `exit` beenden.
+
+Das Handling der Kommandos übernehmen die Methoden der Datenstruktur Command. Beachten Sie, Ihre derzeitige Shell, mit der Sie selbst im Labor arbeiten (labshell), wird nicht einfach beendet wenn ein Kommando fehlerhaft ist oder nicht ausgeführt werden kann. Ebenso soll Ihre Shell nur bei dem Kommando `exit` beendet werden.
+
+Die main() Funktion selbst hat somit wenig zu tun, sie muss lediglich eine Instanz des Datentyps Shell starten und das Ergebnis auswerten. Ist das Ergebnis 'Ok' so wird das Programm mit dem Exitcode 0 beendet. Tritt intern bei der Benutzung einer Funktionalität Ihrer Shell ein Fehler auf, welcher nicht von Ihnen behandelt werden kann, so wird die Shell mit dem Exitcode 1 beendet.
+
+```Rust
+...
+let mut s = Shell::new(..);
+    match s.start() {
+        Ok(_) => process::exit(0),
+        Err(_) => process::exit(1),
+    }
+...
+```
+
+## Implementierung
+
+### *Shell* Datenstruktur
+
+Die Datenstruktur 'Shell' hat folgende Felder:
+
+```Rust
+struct Shell<R, W> {
+    pub reader: R,
+    pub writer: W,
+    pub should_exit: bool,
+    pub name: String,
+}
+```
+
+'reader' ist der Input Kanal Ihrer Shell und 'writer' der Output Kanal. Das Flag 'should_exit' signalisiert Ihrer Loop (siehe unten), dass die Loop beendet werden soll. 'name' ist der Name der Shell, den diese immer am Anfang des Prompts ausgibt, damit diese sich von Ihrer normalen Shell unterscheidet.
+
+Für Ihre Implementierung verwenden Sie folgende Traitbounds:
+
+- R: BufRead
+- W: Write
+
+Um das Verhalten einer echten Shell zu erhalten benötigen Sie für den Reader die Standard-Eingabe und für den Writer die Standard-Ausgabe.
+
+In den Unit Tests werden andere Typen für R und W benutzt. Schauen Sie sich dazu die Tests in `unit_tests_shell.rs` an. Diese sollen Ihnen als Beispiel für eigene Tests dienen.
+
+#### Public Methode *new()*
+
+```Rust
+pub fn new(input: R, output: W, name: String) -> Self
+```
+
+Eine Instanz der Shell wird erstellt.
+
+#### Public Methode *start() -> Result*
+
+Die public Methode *start()* ruft die private Methode *shell_loop()* auf. Die Funktion *start()* ist für evtl. spätere Erweiterungen gedacht, wenn in der Shell vor dem Starten der Loop noch weitere Initialisierungsarbeiten durchzuführen sind.
+
+#### Private Methode *shell_loop() -> Result*
+
+Die Basis Loop einer Shell haben wir bereits in der Vorlesung besprochen. Die Loop wartet auf Eingaben des Benutzers, die dieser mit RETURN abschließt. Die Eingaben werden dann ausgewertet und das Kommando, das sich u.U. daraus ergibt ausgeführt. Danach steht die Loop wieder für Eingaben bereit.
+
+![Loop](png/shell_loop.png)
+
+#### Private Methode *prompt() -> Result<Option<String>, ...>*
+
+Die Funktion gibt den Namen der Shell, den aktuellen Pfad (siehe `std::env`) sowie das ' >' Zeichen, gefolgt von einem Leerzeichen aus:
+
+```text
+bsys-shell /Users/username >
+```
+
+Nach der Ausgabe wartet die Funktion auf Eingaben des Benutzers.
+
+Benutzen Sie zum Einlesen die *read_line()* Funktion. Liefert *read_line()* kein Zeichen, so gibt die Funktion None zurück. Werden Zeichen von *read_line()* eingelesen, so liefert die Funktion die Eingabe des Benutzers zurück.
+
+> Damit bei einem *write!()* Aufruf auf der Konsole auch der String erscheint, muss nach dem *write!()* Aufruf ein *flush()* Aufruf folgen
+
+Wie am Funktionskopf zu erkennen ist, liefert diese Funktion im Erfolgsfall den eingelesenen String zurück.
+
+#### Private Methode *run()*
+
+Diese Methode wird von *shell_loop()* aufgerufen, wenn der Benutzer Eingaben gemacht hat, und daraus ein Kommando geparst werden konnte. Das eigentliche Parsen des Strings geschieht im 'Command' Modul. Das Modul liefert nach einem erfolgreichen Parse-Vorgang ein Kommando zurück, welches dann in run() aufgerufen wird.
+
+Sowohl die Funktion zum Parsen des Strings, als auch die Methoden um die eigentlichen Kommandos auszuführen, platzieren Sie bitte in die Datei `command.rs`.
+
+### 'Command Datenstruktur'
+
+Die Datenstruktur 'Command' in `command.rs` hat zunächst folgende Felder:
+
+```Rust
+enum Command {
+    Empty,
+    Exit,
+    Cd(Option<OsString>),
+}
+```
+
+Die Kommandos bedeuten:
+
+- 'Empty': Keine Eingabe, z.B. hat der Benutzer nur Return, Leerzeichen oder andere Whitespaces getippt.
+- 'Exit': Dieses Kommando bedeutet, dass sich die Shell vor dem Start der nächsten Loop beendet.
+- 'Cd': ein Change Directory Befehl soll ausgeführt werden. *Option* enthält den Pfad zu welchem gewechselt werden soll.
+
+
+Im Modul `command.rs` wird die Trait Methode `FromStr` bereit gestellt, so dass das Objekt Command dieses Trait unterstützt.
+
+```Rust
+...
+fn from_str(s: &str) -> Result<Command, .....> {
+```
+
+Diese Funktion können Sie benutzen, um sich den Input des Users in der Shell analysieren zu lassen. Als Rückgabewert erhalten Sie den entsprechenden `Command`. Somit können Sie im Modul `shell.rs` komfortabel über folgenden Aufruf den Input String in ein Kommando wandeln lassen:
+
+```Rust
+Command::from_str(&line).and_then(|cmd| self.run(cmd))
+```
+
+In der obigen Trait Methode können die einfachen Kommandos wie:
+
+- Empty und
+- Exit
+
+direkt - je nach Input des User - zurück gegeben werden. Für komplexere Funktionen wie **cd** bietet es sich an, in der Trait Methode spezifische Methoden des Datentyps Command aufzurufen. Für jedes Kommando sind in der command.rs zwei Methoden zu implementieren:
+
+- *parse_<command>()*
+- *exec_<command>()*
+
+Für das **cd** Kommando somit:
+
+- *parse_cd()*
+- *exec_cd()*
+
+Die *parse_command()* Methode wird im *from_str()* Trait aufgerufen. Die *exec_<commnad>()>* Methode wird aus dem shell Modul an geeigneter Stelle aufgerufen.
+
+> Ihr **cd** Kommando sollte sich so verhalten wie das **cd** Kommando der labshell. Somit kommen Sie beim Aufruf von **cd** ohne Parameter in Ihr Home Verzeichnis (siehe env::var_os("HOME")). Mit **cd ..** in das Verzeichnis 'darüber' usw.
+
+
+## Externe Crates
+
+Benutzen Sie für Ihre Implementierung nur die externe Crate `nix`.
+
+## Module und Tests
+
+Ob und wie Sie den Code in weitere Module aufteilen wollen ist Ihnen überlassen. Schreiben Sie jedoch Ihre Unit-Tests in der Datei `unit_test_shell.rs` oder als eigenständigen Test, der von 'cargo test' aufgerufen wird, siehe auch [Testing][]. Einfache Tests können auch direkt in die Dokumentation 'codiert' werden, siehe [Documentation Tests][].
+
+Wichtig: Erstellen Sie ausreichend Unit Tests, um möglichst alle Methoden aus `shell.rs` und `command.rs` ausreichend testen zu können.
+
+## Dokumentation
+
+Bei dieser Aufgabe ist Ihre Dokumentation wichtig, um Ihren Programmablauf nachvollziehen zu können. Bitte dokumentieren Sie Ihre Funktionen entsprechend umfangreicher und kommentieren Sie spezielle Kniffe im Code, die Sie verwendet haben.
+
+[Testing]: https://doc.rust-lang.org/book/first-edition/testing.html
+[Documentation Tests]: https://doc.rust-lang.org/book/first-edition/testing.html#documentation-tests

hw6/task2/src/unit_tests_shell.rs

@@ -0,0 +1,55 @@
+#[cfg(test)]
+mod test {
+    use shell::Shell;
+
+    #[test]
+    fn test_prompt_in_memory_with_string() {
+        let input = b"echo";
+        let mut output = Vec::new();
+
+        let mut shell = Shell {
+            reader: &input[..],
+            writer: &mut output,
+            should_exit: false,
+            name: "bsys-shell".to_string(),
+        };
+
+        let output = shell.prompt().unwrap().unwrap();
+
+        assert_eq!("echo", output);
+    }
+
+    #[test]
+    fn test_loop_of_shell_which_wants_to_exit() {
+        let input = b"BlaBla";
+        let mut output = Vec::new();
+
+        let mut shell = Shell {
+            reader: &input[..],
+            writer: &mut output,
+            should_exit: true,
+            name: "bsys-shell".to_string(),
+        };
+
+        let output = shell.start().unwrap();
+
+        assert_eq!((), output);
+    }
+
+    #[test]
+    fn test_loop_with_exit_command() {
+        let input = b"exit";
+        let mut output = Vec::new();
+
+        let mut shell = Shell {
+            reader: &input[..],
+            writer: &mut output,
+            should_exit: false,
+            name: "bsys-shell".to_string(),
+        };
+
+        let output = shell.start().unwrap();
+
+        assert_eq!((), output);
+    }
+}