The disposition of stderr

[dsb@cs.duke.edu (Scott Bigham)]

In my ongoing dialogue with the maintainer of SozobonX, the subject of
stderr has come up.  The xdLibs, with which all the compiler pieces are
built, attaches stderr to file handle -1, which causes tcsh no end of
trouble; for that reason, I'm trying to convince him to fix the xdLibs'
startup code.  For those who haven't been digging in that section of
the code recently ;), here are the relevant lines from the MiNTlibs'
main.c:

== main.c ================================================
/* if stderr is not re-directed to a file, force 2 to console
 * (UNLESS we've been run from a shell we trust, i.e. one that supports
 *  the official ARGV scheme, in which case we leave stderr be).
 */
	if(!*_argv[0] && isatty(2))
	    (void)Fforce(2, -1);

/* deletia... --dsb */

	for(i = 0, f = _iob; i < 3; ++i, ++f) {	/* flag device streams */
	    if(isatty(f->_file = i))
		/* et cetera... --dsb */
==========================================================

Jerry objects (perhaps rightly so) that checking *_argv[0] is not a fair
test, since (he claims) no Atari release notes on the subject of ARGV
have ever indicated that using the ARGV scheme also entailed the
responsibility of doing the right thing with stderr.  The xdLibs' own
spawn() routines, for instance, support the ARGV scheme (at least
purportedly), but not stderr.

Jerry's counter-suggestion is to have the startup code check for the
presence of an environment variable STDERR to decide how to initialize
stderr.  Frankly, the thought makes me shudder.  In the hopes of
averting this catastrophe, I've come to ask if there is any more
reliable way to determine whether one's parent program expects to
receive stderr on handle 2 or -1.  (Yeah, I know, if there were such a
method, the MiNTlibs would be using it, but I'm desperate here).

Thanks.
						-sbigham