Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse From: mouse@thunder.mcrcim.mcgill.edu (der Mouse) Newsgroups: comp.sys.next Subject: Re: NeXT questions Message-ID: <1991Mar26.131040.12132@thunder.mcrcim.mcgill.edu> Date: 26 Mar 91 13:10:40 GMT References: <208@gouche.UUCP> <1991Mar20.085057.1217@news.cs.indiana.edu> Organization: McGill Research Centre for Intelligent Machines Lines: 25 In article <1991Mar20.085057.1217@news.cs.indiana.edu>, jashley@hammerhead.cs.indiana.edu (J. Michael Ashley) writes: > In article <1991Mar20.125440.17013@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >> In article , ersys!drin@nro.cs.athabascau.ca (Adrian Smith) writes: >>> grant@gouche.UUCP (Grant Munsey) writes: >>>> 4) Is the NeXT impl of 4.3bsd fairly faithful...will I finally be >>>> able to compile programs from the net without the SYSVizeing >>>> them? >> They have *no adb*. I don't know *what* possessed them to do away >> with it, but they did.... > I was upset at first that adb is not on the NeXT, but I've since > found gdb to be a more than adquate replacement, both in terms of > functionality and friendliness. As a debugger, so do I. But adb is useful for things other than normal debugging tasks. It makes a passable binary file editor. It can be used to disassemble snippets of data that do not happen to be part of an a.out file. It is the ed of debuggers and is useful for all the reasons ed is useful; notably, it behaves sanely when used as a filter in a pipeline. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu