Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!rutgers!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: Suspending processes (really, about how to answer questions)
Message-ID: <5516@brl-smoke.ARPA>
Date: Tue, 13-Jan-87 17:47:30 EST
Article-I.D.: brl-smok.5516
Posted: Tue Jan 13 17:47:30 1987
Date-Received: Sat, 17-Jan-87 00:52:33 EST
References: <836@A60.UUCP> <2557@phri.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 33

In article <2557@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>The comparison of the Sys5 and BSD
>flavors of job control is just extra verbiage to wade through for the
>novice who simply wants to know how to get his job stopped.

If someone came running down the hall to ask me how to stop
a job he currently has running, then an answer like "type ^Z
and if that doesn't work, you're out of luck" might suffice.
However, I went into more detail in order to steer the novice
in the right direction.  For example, on SVR2.1 or later the
"shl" facility has to be invoked BEFORE the need arises.  I
assume that even a novice is perfectly capable of looking up
"shl" in the index to his documentation to find out more about
it.  (If he doesn't have documentation for it, either he
doesn't have the facility at all, or else he should go find
some reference material; it would be folly to try to relay
complete "shl" usage instructions via this newsgroup.)  It
also really doesn't matter much whether the term "SVR2.1" is
understood, if the user now knows what to look for in his
local system documentation (which is the ultimate authority
on how to do things in his specific case).

I'm from the "don't give a hungry man a fish; teach him how
to fish" school.  My experience has been that limiting
answers to the obvious short, simple, direct answer often
ends up encouraging people to continue with inefficient
approaches to problems.  Therefore I tend to err on the side
of giving extra information, rather than insufficient info.
The extra information about /proc was just to make people
aware that there's a better way of doing things, so they can
nag their salesmen for it rather than demanding BSD-style
job control (for example).  With enough customer demand,
almost anything will eventually be provided by the vendors.