[GRASS5] More Mac OS X Tcltkgrass Tweaks

[Glynn Clements]

Jeshua Lacock wrote:

> > Also, I'm not sure that the above really fixes the problem. AFAICT,
> > the whole point of the "2> @stdout" is so that stderr goes to the same
> > place as stdout, i.e. into the stream which is returned from the open
> > command, and *not* wish's stdout/stderr. But the nature of the problem
> > suggests that wish's stdout/stderr is getting involved.
> >
> > If a command generates an error, do you get the error message in the
> > output window, or in the xterm? It should be the former.
> 
> Hmm, I am not sure if I completely understand, however, if I run the 
> 'd.rast' GUI, provide a bogus file name, click run, I get a tcltk 
> dialog titled 'd.rast output' that says:
> 
>                           d.rast output
>                              Finished.
>    ERROR: Raster map [fooMAR] not available
> 
>    Quit                          Save                         Clear
> 
> So, it seems to be capturing the errors as it should, and otherwise 
> function normally, AFAICT.

That seems OK; so my guess was wrong.

In which case, it seems to be a plain Tcl/Tk bug (rather than an
incompatibility); wish's stderr/stdout shouldn't come into it.

Regardless of whether your test case (puts stdout ...) complains, the
gui.tcl case (open "|... 2>@ stdout" "r") shouldn't. These are two
completely different situations. Your test is writing to wish's
stdout, but gui.tcl is writing to a pipe which is created by the open
function.

The error in the test case could be legitimate. When a background
process writes to a terminal, the write may simply occur, or the
writing process may receive SIGTTOU (by default, this suspends the
process, but it can be caught). The actual behaviour is controlled by
the terminal driver, and can be set using "stty tostop" (writing
process receives SIGTTOU) or "stty -tostop" (write occurs with no
signal).

However, this isn't (or, rather, shouldn't be) relevant to the
behaviour of open with regard to pipes. The "2>@ stdout" should
duplicate the pipe which is used for the subprocess' stdout to the
subprocess' stderr; no terminals should be involved.

There is another possibility, though; something about that open
command might be causing wish itself to write to its stdout/stderr
(e.g. an error message); that would be expected to have the same
result as a simple "puts stdout ...".

Try changing your test script to e.g.

	#!/bin/wish
	set f [open "|ls -l 2>@ stdout" "r"]
	while {![eof $f]} {gets $f line}
	close $f
	exit

Also, try changing your terminal settings, with "stty -tostop".

Yet another thing to try is to wrap the open statement within a catch.

-- 
Glynn Clements <glynn.clements at virgin.net>