Separating stderr and stdout with exec/fileevent
DUPERVAL, LAURENT
I'm writing a little tool for myself to help me buils large applications
faster. Some background: I'm trying to keep up with all the development
of Gnome. Installing tarballs has become a real chore (latest release
has > 20 files. So I've decided to write a Tk program which does
ecerything in one fell swoop: untar a file, configure, run make and make
install. It's actually more involved than that but you get the picture.
I use a text widget to display whatever information is returned by the
exec'd process. The command is run as:
proc execCommand {windowId cmdList} {
if {![winfo exists .window($windowId)]} {
toplevel .window($windowId)
scrolledtext .window($windowId).text
button .window($windowId).close -text "Close" \
-command [list destroy .window($windowId)] \
-state disabled
pack .window($windowId).text
pack .window($windowId).close
update
}
set fileId [open "|$cmdList" r]
fileevent $fileId readable "insertLogLine $fileId $windowId"
}
After a few hours of tinkering, I got it to work reasonably well. I ran
into a situation, though, where configure returned a warning to standard
out which, of course, Tcl interpreted as an error. I then got the
standard error dialog which only contained the output that went to
stderr. What I would like to do, is have the programs run normally and
only trap the stuff that goes to stderr. Then, after the program has
run, I want to pop up a menu that only contains the output to stderr and
giving me a choice of stopping the current build/installation or
continuing and discarding the error.
Is this possible? I'm not sure how to go about testing it because I
develop in the day on NT but test at night on Linux.
Thanks.
--
Penguin Power!
Laurent Duperval - CGI
5 Place Ville Marie, Suite 1600 South, Montreal H3B 2G2
Tel: (514) 870-0879 Fax: (514) 391-2212
EMAIL: mailto:laurent....@bellsygma.com
Ulrich Schöbel
I then got the
> standard error dialog which only contained the output that went to
> stderr. What I would like to do, is have the programs run normally and
> only trap the stuff that goes to stderr. Then, after the program has
> run, I want to pop up a menu that only contains the output to stderr and
> giving me a choice of stopping the current build/installation or
> continuing and discarding the error.
>
> Is this possible? I'm not sure how to go about testing it because I
> develop in the day on NT but test at night on Linux.
>
> Thanks.
>
> --
> Penguin Power!
>
> Laurent Duperval - CGI
> 5 Place Ville Marie, Suite 1600 South, Montreal H3B 2G2
> Tel: (514) 870-0879 Fax: (514) 391-2212
> EMAIL: mailto:laurent....@bellsygma.com
Hi Laurent,
take a look at bgexec in the BLT extension. Maybe this
is wht you need.
Best regards
Ulrich
Alexandre Ferrieux
>
> What I would like to do, is have the programs run normally and
> only trap the stuff that goes to stderr. Then, after the program has
> run, I want to pop up a menu that only contains the output to stderr and
> giving me a choice of stopping the current build/installation or
> continuing and discarding the error.
Simply use the "2>" redirection to a temporary file (as an argument of
exec/open, or within a shell command line).
Now if you think later that you'd actually prefer to have the stderr in
real time, please do a DejaNews here with keywords "fileevent" and
"stderr".
-Alex
Mumit Khan
Of course, all of this works just fine under Cygwin version thanks to
the "join error" (for >1 2>&) bug fix by Ian Taylor as well as his
other changes that are in the Cygnus version; I've never had trouble
with fileevents under win32 either.
I use this extensively for a large simulation front-end that runs jobs
and collects the stdout/stderr while the user can keep on playing with
the front-end.
Regards,
Mumit
Alexandre Ferrieux
>
> Of course, all of this works just fine under Cygwin version thanks to
> the "join error" (for >1 2>&) bug fix by Ian Taylor as well as his
> other changes that are in the Cygnus version; I've never had trouble
> with fileevents under win32 either.
For your information, this 'bug fix' by Ian Taylor is semantically
incorrect. Look at the arguments on the Scriptics page. It only happens
to make things easier for *your* class of uses, but it is utterly
inconsistent with the rest of Tcl's redirection semantics.
Now there's an interesting implication in your last sentence: the Cygnus
version of Tcl seems to be a good answer to the fevent problem (and also
most other 'doze shortcomings I'm sure). Can you refresh my memory about
the visible issues when using a Cygwin-built application ? Is there a
runtime fee ? What about installation ? Can many versions of the runtime
coexist ?
-Alex
Mumit Khan
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
>Mumit Khan wrote:
>For your information, this 'bug fix' by Ian Taylor is semantically
>incorrect. Look at the arguments on the Scriptics page. It only happens
>to make things easier for *your* class of uses, but it is utterly
>inconsistent with the rest of Tcl's redirection semantics.
Thanks for the info. I use an intermediate shell to exec everything, so
didn't bother looking into it.
>Now there's an interesting implication in your last sentence: the Cygnus
>version of Tcl seems to be a good answer to the fevent problem (and also
>most other 'doze shortcomings I'm sure). Can you refresh my memory about
>the visible issues when using a Cygwin-built application ? Is there a
>runtime fee ? What about installation ? Can many versions of the runtime
>coexist ?
Free version is GPL'd; commercial version from Cygnus lets you do what you
want. The one gotcha is that you should have *one* version of similarly
numbered cygwin dll (cygwin1.dll), but then that's the issue with msvcrt
dll etc as well. You can multiple versions in the sense that you can have
a cygwinb19.dll, cygwin1.dll, cygwin2.dll (when it's out), and
applications using it.
Regards,
Mumit
Alexandre Ferrieux
>
> >Now there's an interesting implication in your last sentence: the Cygnus
> >version of Tcl seems to be a good answer to the fevent problem (and also
> >most other 'doze shortcomings I'm sure). Can you refresh my memory about
> >the visible issues when using a Cygwin-built application ? Is there a
> >runtime fee ? What about installation ? Can many versions of the runtime
> >coexist ?
>
> Free version is GPL'd; commercial version from Cygnus lets you do what you
> want.
Okay. So it looks like for an *official* Cygwin-based Win32 port of Tcl
to exist, some kind of deal should be made between Cygnus and Scriptics.
Any hope ?
Side-note for people outside Cygnus: what about David Korn's U/Win ?
Technical issues ? Legal ?
-Alex
Bob Techentin
[snip]
> want.
Actually, the free version of Tcl/Tk is not covered by the GNU GPL.
The GPL says (essentially) "This software is free. Your derivative
software will also be free," which causes a problem with some
commercial users. Tcl/Tk is covered by a Berkeley license, which
basically states "Do what you want. Don't sue me."
Bob
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html
Mumit Khan
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
>
>Okay. So it looks like for an *official* Cygwin-based Win32 port of Tcl
>to exist, some kind of deal should be made between Cygnus and Scriptics.
>Any hope ?
It's upto the customer/user, not up to Scriptics. Tcl/Tk is already free
and part of Cygwin distrib. However, the applications you ship that is
linked against the free/GPL'd cygwin becomes GPL'd unless you buy a
commercial version from Cygnus.
btw, I may have misspoken about fileevent issue -- I've never tried
fileevent on a changing file, but rather use on a pipe when I exec
apps. I don't know if that doesn't work with the stock version. My
usage is so simple that it may just not be affected by the deeper
problem with the Tcl windows port.
>Side-note for people outside Cygnus: what about David Korn's U/Win ?
>Technical issues ? Legal ?
UWIN is a commercial product and not redistributable. I have patches
for it somewhere, and I believe I have 8.0p2 binaries available on my
site.
All the non-native win32 ports have the same issue -- you'll need to
do some modifications to the windows side to make sure pathnames and
filesystem mounts are translated correctly, process environment and
current directory is kept in sync with the runtime, etc.
You had mentioned Interix at one point (I have patches for that too),
and that's a competely different beast, besides the fact that it's a
NT-only product. It's Unix for all purposes, so you'll be using the
X interface.
Regards,
Mumit
Jean-Claude Wippler
[Alexandre Ferrieux about a free Tcl under Cygwin]
> It's upto the customer/user, not up to Scriptics. Tcl/Tk is already
> free and part of Cygwin distrib. However, the applications you ship
> that is linked against the free/GPL'd cygwin becomes GPL'd unless you
> buy a commercial version from Cygnus.
[comments about UWIN/Internix snipped]
> Regards,
> Mumit
The way I understand it, code compiled with Cygnus B20.1 falls under GPL
when compiled in default mode, but does not fall under GPL when compiled
with the "-mno-cygwin" flag - is that correct?
-- Jean-Claude
Mumit Khan
Jean-Claude Wippler <j...@equi4.com> wrote:
>
>The way I understand it, code compiled with Cygnus B20.1 falls under GPL
>when compiled in default mode, but does not fall under GPL when compiled
>with the "-mno-cygwin" flag - is that correct?
Correct. When you use -mno-cygwin, the resulting executable does not use
Cygnus runtime, but rather uses Microsoft runtime.
Regards,
Mumit
Alexandre Ferrieux
>
> In article <36B6C7...@cnet.francetelecom.fr>,
> Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
> >
> >Okay. So it looks like for an *official* Cygwin-based Win32 port of Tcl
> >to exist, some kind of deal should be made between Cygnus and Scriptics.
> >Any hope ?
>
> and part of Cygwin distrib. However, the applications you ship that is
> linked against the free/GPL'd cygwin becomes GPL'd unless you buy a
> commercial version from Cygnus.
Hence my suggestion of a deal at company level, to remove the burden
from the individual Tcl developers...
> btw, I may have misspoken about fileevent issue -- I've never tried
> fileevent on a changing file, but rather use on a pipe when I exec
> apps.
That's good you never tried - fileevent is *not* (at all) supposed to
work with 'changing files' (I guess you are thinking about something
like tail -f). Communication channels (pipes, sockets, terminals, other
devices...) are its sole purpose in life !
> I don't know if that doesn't work with the stock version.
Believe me, it doesn't ;-). (You don't read c.l.t so often, do you ?)
The behavior is the following: fileevents on everything but sockets
(which work because they are not very well integrated in the Windoze
mess !) constantly *fire*, even when there are no data. If you don't
observe *this* with the cygwin port, I'd bet it works. A simple reason
for that: if cygwin didn't implement select() correctly, it would be a
known fact !
> UWIN is a commercial product and not redistributable.
I guess you mean that a UWIN-compiled (commercial) app (needing some
runtime too) *must* pay back a fee to ATT research. Again, why couldn't
Scriptics arrange for a special deal ?
> You had mentioned Interix at one point (I have patches for that too),
> and that's a competely different beast, besides the fact that it's a
> NT-only product. It's Unix for all purposes, so you'll be using the
> X interface.
Yes, I know, I have purchased one Interix seat. However, it still has
two bleeding misfeatures:
- no rooted filesystem (/bin/awk must be replaced by
$INTERIX_ROOT/bin/awk in all your Makefiles/scripts/configure.in)
- no generic access to NT drivers. Under /dev/ you have only the strict
minimum: /dev/console, /dev/null, /dev/proc, /dev/[pt]ty*. Not even a
/dev/zero !!!
Though promising, it is still an immature thing to me.
-Alex