Putting trouble-shooting into binaries

[millar!bowles at lll-crg.llnl.gov]

\ From: Lars J Poulsen <lll-crg!salt.acc.com!lars>
\ 
\ > From: brian at ucsd.edu (Brian Kantor)
\ > Subject: The problem with DEBUG (was: Worms and fixing blame)
\ > 
\ > DEBUG in sendmail is invaluable for troubleshooting mail problems;
\ > I use it quite often.  Having DEBUG able to invoke a shell is
\ > inexcusable. Do not make the same mistake so many have in asserting
\ > that DEBUG is the problem, when it is the shell invocation that
\ > really is.  Turning off the debug command was just a convenient
\ > quick hack to stop the shell problem, and as soon as you've patched
\ > out the shell invocation, you can probably re-enable debug.
\ > 	- Brian
\
\ Brian,
\ 	I agree that it is valuable to have trace and debug features for
\ troubleshooting....  What I take VIOLENT exception to, is that the
\ feature is
\     (1) undocumented.
\     (2) turned on by default. I would allow for a complete and suicidal
\ 	test feature so long as it needed to be turned on by a command
\ 	line argument which was not normally turned on in the rc.local
\ 	file as distributed.

Please don't let this degenerate into a list of reasons why debugging
code doesn't belong in binaries. If you've ever done technical support
you'll understand that it's VERY nice to be able to turn debugging on,
on the fly, on a troubled system.

But Lars is right - all such behaviour should be documented, for those
who haven't bought source. Why? Many commercial Unix vendors, sorry to
say, only test what's documented - and this might be the last place to
find such problems before giving them to a customer.

	Jeff Bowles