Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!usc!wuarchive!rex!uflorida!bikini!bb From: bb@sandbar.cis.ufl.edu (Brian Bartholomew) Newsgroups: comp.sys.next Subject: Re: Installing f2c on the NeXT Message-ID: Date: 3 Jan 91 02:52:06 GMT References: <1991Jan2.095723.16706@wuphys.wustl.edu> Sender: news@uflorida.cis.ufl.EDU Organization: /cis/lightning0/bb/.organization Lines: 91 In-reply-to: rdd@wuphys.wustl.edu's message of 2 Jan 91 09:57:23 GMT In article <1991Jan2.095723.16706@wuphys.wustl.edu> rdd@wuphys.wustl.edu (Rakhal D. Dave) writes: > The "make" genie knows about all the previous work that was done and > will not repeat it. The "magic" is is kept in the file "Makefile". The contents of this file is read and acted upon by the "make" program when you enter the command "make". The "Makefile" contains lists of which files are dependent on which other files, and also contains instructions to create one from the other. For example, the result of one invocation of the C language compiler, an object file "data.o", is listed as being dependent on the C language source file "data.c". If the file data.o does not exist or is older than the file that produces it (data.c), the corresponding command line (cc -O -c data.c) is executed. In this way the whole program is represented as a tree of dependencies, with the finished program at the top (f2c), C and other language source files at the bottom (data.c, equiv.c, format.c, tokens, etc.), and intermediate results from compilers and whatnot in the middle (data.o, equiv.o, gram.in, lex.c, and so on). The "make" program is extremely versatile, and is used in the UNIX world to automate all sorts of things. It lets you document the building sequence of a complex program or project, and as a bonus you can get the computer to read it and do the work for you. Some UNIX users might argue that the automation benefit was more important than the documentation benefit :-) For more information on "make", type "man make" at a shell prompt, or search for it in the Digital Librarian in the UNIX manuals. > Before f2c is seen in /bin and recognized as a command I had to reboot. > There must be an easier way which I hope someone lets me know. > For some reason a.out was not recognized as a command immidiately when > I was in root. On logging out and logging in as "me" a.out was seen as > a command and executed. Hopefully someone will illuminate me about > this. (Note that a.out was executable in root still it did not run.) > How to get the computer to recognize an addition to /bin without > rebooting. > Why doesn't root recognize a.out. The program that reads your typed input in a terminal window, performs certain manipulations, and starts up programs for you, is called a "shell". I suspect that you are running the particular flavor of shell called "csh", pronounced "C-Shell". (Yes, that is a pun. UNIX programmers like puns.) The shell knows how to find the programs you ask for by searching for them in directories named in an environment variable named "path". However, as there can be as many as a thousand programs total in the directories named in your path, the shell searches each directory in your path at startup time and caches the names and locations of programs away for future reference. When you add a program to one of the directories "on your path", you need to tell the shell to throw away its cache and re-read the directories, so that it may notice your new program. The csh command to do that is "rehash". This command will fix all of the problems you have noticed of this type. For more information on "csh", type "man csh" at a shell prompt, or search for it in the Digital Librarian in the UNIX manuals. > While I never managed to get the Sun4 totally free of background > processes to make a useful comparision of speed, I got the distinct > feeling that if the Sun4 had even 1 background process other than mine, > the NeXT 040 would win out.( Note that this is assuming the NeXT had > only this one process running). I will report with hard facts on this > when an opportunity arises. Sorry, but speed determinations of this type are notoriously hard to do with any sort of scientific rigor. For instance, there is no UNIX machine alive today that will effectively function with "1 background process other than mine". You might notice that your NeXT was running a rather demanding windowing system at the time, and perhaps the Sun was not. Or, perhaps it was. -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!mathlab.math.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu