Observations (was: Gripes about /bin/sh AND /bin/csh)

[guy at sun.UUCP]

> "The only STUPID question is the one that is never asked.." - Anon.

Questions which can be answered just by looking up the answer in a reference
book are stupid *if* it doesn't take more knowledge to find the answer than
to answer the question.  Some questions *do* fall under that heading, and
the person who is asked the question is perfectly within their rights to
tell somebody to RTFM.

> It is sad but true that the manuals provided with this system are often
> very poorly written...

Yes, and often incomplete, and often sometimes just *wrong*.  If somebody
gets caught by one of those, there's nothing wrong with them asking.
(Recently, somebody asked why a call to the 4.2BSD "gethostbyaddr" routine
wasn't working.  It wasn't working because he was passing a printable
representation of the address to the routine, rather than a binary
representation; however, it isn't stated in the "gethostent" manual page
that the binary representation is required, it's just implied.)

However, there are some questions, asked on the net among other places,
which indicate that the asker didn't even *try* to look the answer up.  I
don't have an opinion on whether the "/bin/sh" and "/bin/csh" are of this
form.  In at least one case, you could have argued that the documentation
isn't good enough.  The fact that a shell script can open multiple files and
keep them open throughout the script, in order to read from or write to
them, is somewhat obscurely buried in the description of the "exec" command.

> As an example; the function 'expr'. Nowhere in the manual is
> stated that expr has a 'index', 'length', or 'match' capibility,
> NOR does it state that it is limited to positive, non-floating
> point numbers.

Watch it.  The "index", "length", and "match" functions, along with the
"substr" function, were deleted in System V.  The trouble is that, since
they are reserved words, they cause problems if strings "index", "substr",
"length", or "match" appear in an "expr" expression; they are treated as
reserved words, not as strings.  "match", by the way, performs the exact
same operation as the ":" operator, just with a diferent syntax, so even
without "match" it has a "match" capability.  I have no idea why they were
undocumented, but by and large we should be grateful that they were,
otherwise it would have been difficult as all hell to back them out.  It
would be nice if those capabilities could be provided, but it would have to
be done in such a way as not to cause certain character strings to be
unusable as data.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)