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

[David Tilbrook]

Tim Writer wrote:
> David Tilbrook <dt-hKuJ9UrQZDM at public.gmane.org> writes:
> 
> 
>>Lennart Sorensen wrote:
>>
>>>On Sat, Jan 24, 2004 at 06:03:37PM -0500, David Tilbrook wrote:
>>>
>>
>><snip>
>>
>>>>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.
>>>
>>>I wonder what they decided they should connect those to if they weren't
>>
>>>already connected to a tty.
>>>
>>
>>The fix was to open /dev/null for read for 0 and for write for 1 & 2
>>obviously.  That works fine and avoids problems that arose.
>>
>>Given the special and unfortunate special cases of std{in,out,err}
>>and the lack of an fdreopen() some programs get twisted when an open
>>yields a special fid.
>>
>>The unfortunate thing is that this problem has arisen again after
>>20 years.
> 
> 
> Here's a stupid suggestion.  Change your FVWM2 menu entry to run a simple
> wrapper script:
> 
>     #!/bin/sh
>     exec realprogram ${1+"$@"} </dev/null >/dev/null 2>&1
> 

My point was that any program that execs another should ensure that
std{in,out,err} are approrpiately open and will remain open when
the exec happens.

There are many programs that fail when invoked with invalid fids
0, 1, or 2.  In fact on some systems fid 3 is supposed to be open
Read/Write from/to the controlling tty.

It appears that fvwm2 actually execs my gui with fid 0 set to a socket
which then gets closed under certain conditions, perhaps due to a fcntl 
setting.

I have already compensated within the .fvwm2rc, but this is a hack
and should not be necessary.

-- dt
--
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