In examining their replies, I determined that my main problem is
an inability to comprehend just what tcl means by "failure".  In
trying to track this down, I documented a number of cases in which
[catch {exec foo}] returned 1 when foo returned 0.  I've boiled it
down to the following curious case:
        % cat foo.c
        #include <stdio.h>
        main() {
                fprintf(stderr,"\n");
                exit(0);
        }

This program clearly exits normally; sh, ksh, csh and perl all agree
on this.  But wish claims that foo fails:
        % wish
        % catch {exec ./foo} val
        1
        % puts \"$val\"
        ""

It appears that tcl considers a program to have failed if: 1) it returns
a nonzero exit status; 2) it writes *anything* to stderr; 3) possibly
other conditions that I haven't yet diagnosed.

Is this true?  Is it documented?  Is it reliable and portable?  What
(if anything) goes in the 3) slot?

The problem with this, of course, is that Unix libraries are full of
programs that write informative messages to stderr, but if the problems
can be fixed or somehow handled, they still succeed and exit normally
(i.e., with a 0 status).  Some demented programs (e.g., stty) even write
their normal output to stderr on some Unix systems.  When called from a
wish script, they are treated as having failed, despite a 0 exit status.

It appears that the only solution to this is to write a wrapper that
execs the program, and eats the stderr output so that tcl doesn't see
it.  Is this the correct interpretation of the situation?  Is there
a more direct solution here that doesn't involve an extra process whose
sole function is to suppress (or redirect) stderr output?

(Note that I'm not criticising tcl's approach; I'm just trying to
understand it.  I've had a lot of problems with wish scripts harassing
the poor users with error dialogs boxes that they don't stand a chance
of understanding; when I look at them, I don't understand either why
wish is harassing them about non-errors.  To make it work right, I
must reach some minimal understanding of what tcl considers an "error",
and I frankly don't understand the Book's explanation, as is proven by
the fact that my wish scripts don't behave as I expect.)

--

  The most important part of any research publication is the paragraph
  near the end which begins with "Further research is needed ...".

: Is this true?  Is it documented?  Is it reliable and portable?  What
: (if anything) goes in the 3) slot?

From the exec man page:

     If any of the commands in the  pipeline  exit
     abnormally or are killed or suspended, then exec will return
     an error and the error message will include  the  pipeline's
     output  followed  by  error messages describing the abnormal
     terminations; the errorCode variable will contain additional
     information about the last abnormal termination encountered.
     If any of the commands writes to its standard error file and
     that  standard error isn't redirected, then exec will return
     an error;  the error message  will  include  the  pipeline's
     standard  output, followed by messages about abnormal termi-
     nations (if any), followed by the standard error output.

Under the exec.n man page is described most of what you are asking, along
with the catch.n man page and a nebulous reference to comands exiting
'abnormally'.  But the bottom line is that if you are going to invoke 'standard'
unix utilities, you are probably going to need to write either wrappers or
redirect their stderr, etc. on the command line to keep tcl from treating
these as errors.

Since unix commands are so non-standard, there is no way to pick a value
from return which would properly indicate an error in all cases.  The
most command value though is 0, which is what Tcl choses.  One could
take the approach to either write tcl wrappers for all unix commands,
or write a unix wrapper for each non-standard command and invoke it
I suppose.
--

:s In search of a new WWW home...
:s Unless explicitly stated to the contrary, nothing in this posting should
:s be construed as representing my employer's opinions.