fvwm2 causes stdin to be closed when execing within tcl/tk

[David Tilbrook]

I have uncovered a bizarre behaviour in RH9.0 fvwm2 and tcl/tk
that is impossible to debug.

I have a gui that contains many statements of the form:

	[catch {eval exec ...} ...]

When this gui is invoked via a menu entry in fvwm2, the standard
input for the program being invoked is not open (i.e., fid 0
is not open).

Yet when invoked from an xterm window, even if detached,
the programs are invoked with a valid fid 0.

The reason that it is impossible to debug is that the environment
in which the problem occurs is not one that can run gdb or
even report diagnostics in a useful manner.

Given the different behaviours are due to the gui's invocation,
does anyone have a suggestion as to the cause?

My best guess is that somehow that tcl/tk does a:

	fcntl(0, F_SETFD)

but why only if invoked from fvwm2?

What state information that is exported to exec'd children
could possibly result in such a bizarre behaviour?

Any why doesn't crt0 ensure that fids 0,1,&2 are open?
See below.

-- dt

P.S.	Coincidently one of the bugs I discovered and reported in
	1983 w.r.t. BSD 4.1c was that a number of programs that
	did not work correctly when fid 0 was not open (e.g. cpp).
	The BSD folks actually extended crt0.o to ensure that
	fids 0, 1, and 2 were open.
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml