[m]me@faui0sr0:/proj/i4sp/pub/aufgabe4$ ./clash
/proj/i4sp/pub/aufgabe4: &
/proj/i4sp/pub/aufgabe4:[/m]
Scheint nicht so. Ich denke aber nicht, dass das ein großes Problem ist, v.a. weil es nicht genauer spezifiziert wurde.
ok jetzt bin ich verwirrt. Als ichs gestern getestet hab ist nämlich auch nichts passiert, da hab ichs in ubuntu über ssh probiert. Als ich das jetzt grad gelesen hab hab ichs über puTTy noch schnell getestet, da hatte ich dann auch Signal11 wie BastiW auch. Sehr seltsam…
Ah ich weiss jetzt warum, drück einfach nochmal Enter, dann kommt das Signal = 11 auch.
SIG11 ist SIGSEGV… ich kann mir nicht vorstellen, dass die Referenzimplementierung bei sowas schon segfaultet.
/proj/i4sp/pub/aufgabe4: cd
cd: Bad address
/proj/i4sp/pub/aufgabe4: &
/proj/i4sp/pub/aufgabe4:
Signal [&] = 11
/proj/i4sp/pub/aufgabe4:
OK, ich hab mich geirrt, da hat die Referenz wohl ein kleines Fehlerchen…
http://pbot.rmdir.de/565ac744c378d3839e8ae501220787ac
Die “Referenzimplementierungen” sind leider in der Regel auch eher schnell und mehr schlecht als recht hingehackt 
(der Segfault tritt allerdings in der libc und nicht in der Shell selbst auf)
Beim Kompilieren mit -Wall -Werror -ansi -pedantic kommt dann diese nette Meldung (und ja, ich habe #include <limits.h>
clash.c:13: error: âPATH_MAXâ undeclared (first use in this function)
da fehlt noch -D_POSIX_SOURCE
Mein Programm verhält sich auf jeden Fall genauso. Darf man denn dann daraus schließen, wenn es sich wie das Testprogramm verhält, dass das eigene Programm richtig ist?
Nein, denn das Testprogramm ist nicht fehlerfrei. Der Grund warum wir überhaupt diese Demoprogramme ins pub legen ist, dass früher manche Teilnehmer sich bei diversen Aufgaben gar nicht vorstellen konnten, was am Ende eigentlich rauskommen soll, weil sie unter dem Begriff „Shell“ vielleicht den ganzen Terminalemulator o.ä. verstanden haben.
Ich hab die beiden Probleme, die ihr gestern erkannt habt (und die letztes Jahr übrigens niemandem aufgefallen sind, zumindest hat es uns niemand mitgeteilt ;-)) auch gefixt.
Folgendes Problem: In meinem wsort stand als Kommentar, dass man realloc immer mit einem Temp-Zeiger aufrufen solle, da der alte Speicherbereich im realloc-Fehlerfall ja sonst nichtmehr adressierbar ist, das hat mich jetzt da schon verwirrt, da ich ja im realloc-Fehlerfall eh mein Programm mit exit(1) beendet hab, weils ja überhaupt keinen sinn macht, es weiterlaufen zu lassen wenn kein Speicher dafür mehr frei ist.
Ich versteh denn Sinn dahinter nicht ganz, wieso ich einen Temp-Zeiger verwenden muss, wenn im Fehlerfall eh das Programm beendet wird und ich somit den alten Speicher eh nichtmehr adressieren muss. Kann mir das mal einer erklären?
müssen wir in strtok wirklich " \t\n" verwenden?
ist bei mir error: unknown escape sequence: ‘\305’
rufe ich es mit richtigen parameter auf strtok(cmdline," \t\n")?
Nein, wenn Du danach einen exit machst und den alten Speicher nicht mehr brauchst, musst Du Dir die Adresse auch nicht aufheben. Erklären können sollte Dir das im Zweifelsfall Dein Übungsleiter, der hat den Kommentar ja schließlich draufgeschrieben 
Komisch. Der gcc sollte sogar die Escape Sequenz \305 kennen und akzeptieren (zumindest tut er es hier), woher die aber in " \t\n" sein soll ist mir fraglich.
Sachen die den Fehler beheben koennten:
- Encoding der Source Datei pruefen
- Sicherstellen dass das " \t\n" keinerlei Sonderzeichen (die durchaus auch einmal im Editor unsichtbar sein koennen) enthaelt, diese koennen auftauchen wenn man Text z.B. aus einem Pdf kopiert, dann kann es auch sein dass man ein Zeichen bekommt das zwar aussehen (oder viel mehr so dargestellt wird) wie das Zeichen, das man haben will, aber in Wirklichkeit ein anderes ist
- Tricksen: falls der Kompiler wirklich kein \t und \n kennt einfach \t durch \11 und \n durch \10 ersetzen und schauen ob er die Octalrepraesentation schluckt … oder nicht
- Rechneruebung
Den oktalen Newline schon mal sicherlich nicht 
(rechne nochmal nach). Zum eigentlichen Problem kann ich ohne das Originalsourcefile leider auch nur meine Glaskugel befragen, und die liefert grade keine Antwort…
Hab zwei kleine Fragen: Sollen wir beim Beenden mit STRG-D auch alle gestarteten Prozesse abschiessen?
Und: Dürfen wir sysconf(_ARG…) einmalig allozieren, oder ist das zu üble Speicherverschwendung (ist ja schon im MB-Bereich)?
Nein, einfach leben lassen. Um das spätere Begräbnis der zu diesem Zeitpunkt noch lebenden Kinder wird sich der init-Prozess in seiner Funktion als „Waisenhaus“ rührend kümmern.
Das ist kein Problem, die CIP-Rechner haben allesamt Arbeitsspeicher im GiB-Bereich.
Ok danke!
kurze frage:
in welchem maße wird eine fehlerbehandlung bei chdir() erwartet?
Schau doch mal in die Manpage. Es gibt diverse Gruende fuer ein Fehlschlagen von chdir().
Und was wuerde dir als Benutzer einer Shell jetzt sinnvoll erscheinen? Willst du wissen, warum es nicht geklappt hat (z.B. mangelnde Rechte, oder Nichtexistenz)? Willst du danach mit der Shell weiterarbeiten koennen, z.B. einen Tippfehler im Pfad korrigieren?
Ich find das jetzt wirklich nicht raetselhaft, was hier das richtige[sup]tm[/sup] Verhalten ist. 