Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!apple!bionet!agate!ucbvax!decwrl!labrea!sri-unix!quintus!ok From: ok@quintus.uucp (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: #include search paths Message-ID: <669@quintus.UUCP> Date: 13 Nov 88 06:57:28 GMT References: <1866@loral.UUCP> <2899@ingr.UUCP> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 32 In article <2899@ingr.UUCP> crossgl@ingr.UUCP (Gordon Cross) writes: >In article <1866@loral.UUCP>, jlh@loral.UUCP (Physically Pffft) writes: >> When I have a line like '#include ' I was under the impression >> that /usr/include was searched for fred.h first due to the use of <> instead Quick reminder: no, /usr/include/ is searched _last_ whichever form you use. >There seems to be some confusion between various documents I checked >regarding this. > On the form, > Harbison & Steele say that it "typically does *not* search for the file > in the same directory in which the file containing the #include command > was found, but only in certain standard places according to implemen- > tation dependent search rules." This word "typically" would seem to > allow to be searched for like "fred.h" should the compiler > writer wish it. Hummm, so far we seem to be up the proverbal creek > without the required paddle!! :-) I doubt that such was their intention. The point is that every compiler which supports the -I flag permits this kind of thing: cc jim.c -I. where jim.c contains the line #include According to all the UNIX manuals _and_ Harbison & Steele, this will look for fred.h in the current directory first, and that's the directory containing the source file. In fact we can state this as a general rule for UNIX C compilers: if there is at least one -I option in the command line and the first -I option is -I., the difference between ".." and <..> disappears.