regcmp(1)

[Guy Harris]

> I have had several letters along this line.  But I also have had a letter or
> two saying that some pre-processors will only #include files with the .h
> suffix.  Is this a rare occurence?

I sure hope so.  Any compiler that doesn't take

	#include <...>

and use the "...", unadorned and uncensored, to find the file in the "standard'
include directories shouldn't be discarded lightly; it should be thrown back at
its vendor with great force.  If it, for example, supplies the ".h" as a
"favor", so that you can say

	#include <stdio>

or, worse, *refuses* to work if you say

	#include <stdio.j>

the person who decided to provide those features should be gently chastised if
it's their first offense and shot if it's their second.  (The first feature is
useless because anybody who wants this stuff to work on a wide variety of UNIX
systems has to do "#include <stdio.h>" anyway; it also happens to follow the
UNIX "cc" convention that you mention the full name of the source file, ".c"
suffix and all.  The second one is a botch: if "stdio.j" is a typo, it will
probably be detected when the system fails to find "stdio.j"; if it does find
"stdio.j", I think the chances are good that it's not C code and the compiler
will barf; if it *is* C code, maybe it wasn't a typo and it was *supposed* to
be included.)

Now, I happen to *like* the convention that include files' names end with ".h"
- it makes header files easier to find, and makes it easier to guess that a
file *is* a header file - but that's a different matter.

Then again, I also happen to like REGEXP(5) better than REGCMP(3X), because 1)
it's what "ed", "sed", "pg", etc. now use, 2) it's in the SVID
(REGEXP(BA_LIB)), which REGCMP(3X) isn't, and 3) it's not in the "-lPW"
library.  With REGEXP(5), the only thing I have to include is <regexp.h>, and
that ends with ".h"....  (No arguments about the implementation technique,
please; arguments 1), 2), and 3) - especially 2) - weigh much more than any
such arguments, at least in my book.  I can rely on REGEXP(5) being on systems
more than I can rely on REGCMP(3X) being on them.)