Re: frage zu buch

> Deine Zeilen sind ziemlich seltsam umgebrochen (hab's ab-
> sichtlich nicht korrigiert, damit Du's sehen kannst).
> Üblicherweise wird empfohlen, nach spätestens 72 Zeichen
> eine neue Zeile anzufangen. Wenn Du das nicht manuell
> machen willst, kannst Du /usr/bin/fmt verwenden oder par
> (ist in den Ports).
>
hmm weiss nicht warum, aber ich werd das gleich mal nachschauen.
>
> > oder welche grafierenden aenderungen sich seit dem erscheinen des
> > buches
> > ergeben haben.
>
> Die kanonische Antwort würde hier vermutlich "UTSL" lauten
> (Use the Source, Luke!).
>
nnneeeeiiiinnn darth vader, du bist nicht mein vater *wein*

ok mal schauen ob die macht mit mir ist ;)

>
> Bei konkreten Verdachtsfällen kannst Du einfach erstmal in
> die betreffende manpage schauen. Nicht nur jedes Kommando
> hat unter FreeBSD eine manpage, sondern auch jeder Syscall
> und jede Libraryfunktion.
>
> In einigen manpages sind auch Informationen zur "History"
> der betreffenden Funktion zu finden.
>
> Schließlich findest Du auf http://www.freebsd.org/ auch
> eine Sammlung von manpage-Sätzen aus diversesten histori-
> schen Systemen. Dort kannst Du z.B. gucken, was in einer
> bestimmten manpage unter 4.2BSD stand und das mit dem
> aktuellen Stand von FreeBSD vergleichen.
>

juchu, das sind genau die antworten die ich gebraucht habe.

>
> Das bedeutet i.allg., daß das Programm versucht hat, auf
> eine Stelle im Speicher zuzugreifen, auf die es nicht zu-
> greifen darf (weil die Stelle nicht zum Programm gehört,
> oder weil sie read-only ist). Typischer Fall ist z.B. die
> Dereferenzierung eines Nullpointers. Häufig sind es auch
> Folgefehler, die auf ein Problem hindeuten, das weiter
> zurückliegt im Programmablauf (z.B. ein Pointer läuft
> "Amok", irgendwo wurde zu wenig Speicher reserviert o.ä.);
> in solchen Fällen kann es schon kniffliger sein, dem auf
> die Schliche zu kommen.
>
> Compilier das Programm doch mal mit -g (und ohne -O), und
> achte darauf, daß Deine Resource-Limits für Corefiles nicht
> auf null gesetzt sind (je nach Shell "unlimit" oder
> "ulimit"). Wenn das Programm dann mit SIGSEGV stirbt,
> sollte es eine Datei <binary>.core hinterlassen.
>
> Dann gib mal ,,gdb <binary> <binary>.core`` ein. Am gdb-
> Prompt tippe mal "where". Dann kriegst Du einen Stack-
> trace, der Dir schonmal ganz genau sagt, an welcher Stelle
> der SIGSEGV ausgelöst wurde. Mit "print" kannst Du Dir
> auch Variableninhalte zum Zeitpunkt des Unglücks anzeigen
> lassen. gdb bietet noch eine Menge anderer Features, die
> Du nach und nach bestimmt kennenlernen möchtest. ;-)
>
> Wenn Du das Problem nicht findest, es aber auf ein über-
> schaubares Codefragment eingrenzen kannst, kannst Du das
> Fragment auch gerne mal hierher schicken.
>

hmm mit dem debuggen bin ich grad mal noch nit durch ;)
aber ich probiers einfach mal.
entweder klappts oder nicht.

btw. ich benutze mutt und vi, allerdings bin ich recht neu
zu diesen dingen ;) netscape geschaedigt.

aber ich gelobe besserung.

danke fuer die hilfe.

-- 
gruesse 
joerg "joerch" buechner
mailto: helix(at)mayn.de
subject: i know fraggin nothin, bastich!
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message