Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!sun-barr!newstop!sun!turnpike!argv
From: argv%turnpike@Sun.COM (Dan Heller)
Newsgroups: comp.windows.x
Subject: Re: redirecting stderr; passing arg lists
Message-ID: <127715@sun.Eng.Sun.COM>
Date: 10 Nov 89 06:42:33 GMT
References: <8911081827.AA12003@turnpike.sun.com> <4338@hplabsz.HPL.HP.COM>
Sender: news@sun.Eng.Sun.COM
Reply-To: argv@sun.UUCP (Dan Heller)
Lines: 30

In article <4338@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes:
> In article <8911081827.AA12003@turnpike.sun.com> argv@SUN.COM (Dan Heller) writes:
> >If you've been reading comp.windows.x, you'll see a very short-lived
> >discussion about how XtAddInput is broken --I recommend *strongly*
> >that you avoid using it till it's fixed.

I feel awful every time I read that :-|  Sorry, XtAddInput is fine..
My apologies to those I may have confused/offended :-)  My previous note
on this issue attempts to discuss the problem of what to do when EOF
is reached.  I can't add to much to that part of the discussion tho,
since I haven't had the time to play with it much more than I already
have ...

However, the whole issue about redirecting stderr is still viable.
You can use the code I explained in the original message to redirect
stderr of forked programs or even your own program to a pipe in which
you can read it and send the data to a text widget/object of some kind.
This is quite useful..

> I seem to have missed the "short lived iscussion about how XtAddInput is
> broken". Would anyone happen to have it archived anywhere? Can you
> mail it to me, or repost it?

It's about 100 messages back from this one (depending on your new server),
and having reread it, you're not missing a thing :-)

> 		  Human-Computer Interaction Department
That sounds scary ...or kinky.   ;-)

dan