Aufgabe 4

[madcoma]

---

ah, sorry ich meinte eigentlich waitpid()…

was ist da die richtige reaktion auf einen fehler?
soll sich clash beenden, da ja scheinbar etwas mit der kernaufgabe einer shell (ausführung von kommandos) nicht stimmt ?
auf der anderen seite erscheinen mir die fehler in der manpage alle so aus, dass sie entweder nur durch programmierfehler entstehen oder “übergehbar” sind, also nicht unbedingt explizit behandelt werden müssen…

was wird da von euch erwartet?

[Raim]

---

Bei waitpid() in der Schleife ist es ja sowieso erforderlich anhand der errno zu unterscheiden, was für ein Fehler aufgetreten ist. Beim Warten auf den Vordergrundprozess sollte nur dann ein Fehler auftreten, wenn eine falsche PID übergeben wird. Die Fehler muss man in beiden Fällen behandeln, aber das Programm kann ja sinnvoll fortfahren.

[madcoma]

---

ok, danke

[disaster]

---

ich hab nochmal ein paar fragen zum makefile:

1. muss es auch wieder ein install, das die ausführbare datei ins andere verzeichnis kopiert, sowie ein clean besitzen? oder einfach nur kompilieren?

2. muss man beim erzeugen der .o dateien auch bereits die ganzen flags angeben (-ansi -pedantic -Wall -Werror -D_POSIX_SOURCE), oder nur beim kompilieren von .o zu ausführbare datei?

[placebo]

---

1. fand ich auch nicht ganz eindeutig gestellt, habs einfach mal gemacht, ist ja nicht so der Aufwand.

2. Das Erzeugen der .o-Dateien ist ja das Kompilieren, also da die Flags. Mit gcc -o rufst du dann den Linker auf. (ohne weitere Flags (in dem Fall))
   edit: du kannst dir ja nochmal das Makefile aus der Aufgabe 3 anschauen.

[Kieren]

---

die Objectfiles müssen natürlich auch mit den compiler flags compiliert werden.

[Mich]

---

[quote=Mikey:1259353667]
Den oktalen Newline schon mal sicherlich nicht :-D[/quote]

Fatal LUT error: Read fail

[infirmatiker]

---

Ich rufe in meiner clash abort() auf wenn z.B. ein malloc() oder fork() fehlschlägt, also ein nicht-korrigierbarer Fehler auftritt.

Aus der man page:

DESCRIPTION
The abort() first unblocks the SIGABRT signal, and then raises that signal for the calling process. This
results in the abnormal termination of the process unless the SIGABRT signal is caught and the signal
handler does not return (see longjmp(3)).

   If the abort() function causes process termination, all open streams are closed and flushed.

   If  the  SIGABRT  signal is ignored, or caught by a handler that returns, the abort() function will still
   terminate the process.  It does this by restoring the default disposition for SIGABRT  and  then  raising
   the signal for a second time.

"abnormal termination of the process " … ist das nicht genau das was ich haben will?

[Raim]

---

@infirmatiker

Ich rufe in meiner clash abort() auf wenn z.B. ein malloc() oder fork() fehlschlägt, also ein nicht-korrigierbarer Fehler auftritt.

Überleg dir nochmal, ob ein fehlgeschlagener fork() wirklich „nicht-korrigierbar“ ist und ob du da wirklich die Shell beenden willst.

Als Fehlerbehandlung von malloc() würde ich exit(EXIT_FAILURE) benutzen. abort() erzeugt üblicherweise zusätzlich einen core dump, den man aber nur zum Debuggen braucht. Daher braucht man das auch nur, wenn wirklich etwas völlig Unvorhergesehenes passiert.

[infirmatiker]

---

@Raim

@infirmatiker

Ich rufe in meiner clash abort() auf wenn z.B. ein malloc() oder fork() fehlschlägt, also ein nicht-korrigierbarer Fehler auftritt.

Überleg dir nochmal, ob ein fehlgeschlagener fork() wirklich „nicht-korrigierbar“ ist und ob du da wirklich die Shell beenden willst.

Stimmt, da kann die shell weiterlaufen… zumindest wenn es eine interaktive session ist. Ein skript, bei dem einfach mal ein befehl ausgelassen wird… vielleicht keine so gute idee.

@Raim

Als Fehlerbehandlung von malloc() würde ich exit(EXIT_FAILURE) benutzen. abort() erzeugt üblicherweise zusätzlich einen core dump, den man aber nur zum Debuggen braucht. Daher braucht man das auch nur, wenn wirklich etwas völlig Unvorhergesehenes passiert.

done. thx!

[Mikey]

---

Bei einem fehlgeschlagenen fork() kann man sicher darüber streiten, ob es sinnvoll ist, das Programm zu beenden, oder nicht. Wenn ein fork() allerdings fehlschlägt bedeutet das in der Regel, dass der Benutzer sein Prozesslimit erreicht hat. In dem Fall wäre es also u.U. durchaus sinnvoll, den Prozess zu beenden und seinen “Beitrag” zur Prozesszahlreduktion zu leisten…

[Mullet]

---

Also mir kommt das vor, als wuerde man bei einem leeren Tank sein Auto verschrotten, um einen Beitrag zur Oelkrise zu leisten.

[arw]

---

Mir kommt das so vor, als wuerde man bei Stau rechtzeitig die Autobahn verlassen um nicht den Stau noch zu verschlimmern…

Nicht alles was hinkt ist ein vergleich mit Autos…

[Mullet]

---

Wenn du den Vergleich noch weiter treiben willst, ist die Shell allerdings meistens der einzige Abschleppwagen auf diesem Streckenabschnitt, der wesentlich mehr zur Stauaufloesung beitragen kann, wenn er den Unfallwagen abschleppt.

[Mich]

---

@Mullet

Wenn du den Vergleich noch weiter treiben willst, ist die Shell allerdings meistens der einzige Abschleppwagen auf diesem Streckenabschnitt, der wesentlich mehr zur Stauaufloesung beitragen kann, wenn er den Unfallwagen abschleppt.

Den Stau aufloesen in dem die Shell forked um ‚kill‘ aufzurufen, oder?

[Mullet]

---

@Mich

@Mullet

Wenn du den Vergleich noch weiter treiben willst, ist die Shell allerdings meistens der einzige Abschleppwagen auf diesem Streckenabschnitt, der wesentlich mehr zur Stauaufloesung beitragen kann, wenn er den Unfallwagen abschleppt.

Den Stau aufloesen in dem die Shell forked um ‚kill‘ aufzurufen, oder?

~ $ type kill
kill is a shell builtin

Praktisch, was?

[arw]

---

-rwxr-xr-x 1 root root 13148 2009-01-11 22:49 /bin/kill*

[Mikey]

---

@Mullet

~ $ type kill
kill is a shell builtin

In der clash ist das sicherlich kein builtin. Ich finde auch das Argument von infirmatiker sehr gut, dass unsre Shell, die den Batchbetrieb nicht vom interaktiven Betrieb unterscheidet, hier wohl besser ein Fail-Stop-Verhalten zeigen sollte, damit Kommandos nicht einfach ausgelassen werden.

[madcoma]

---

koennte mir evtl. jemand bitte die emailadresse von ralf hackner per PN schicken?
wir muessten wegen unserer abgabe nochmal ruecksprache halten und wissen nicht, ob er unter @cip.informatik.uni-erlangen.de erreichbar ist.

schonmal danke

[Kieren]

---

i4sp@informatik.uni-erlangen.de
Wenn ihr es da hin schickt landet es auf jeden fall auch beim Ralf
Und da er euer Tutor ist wird er sich wohl dann auch drum kümmern.