Mail Archives: cygwin/2001/07/15/04:34:59
Hello,
I'm running Windows 98 and Cygwin 1.3.2.
Recently I have compiled NEdit
(! This will not be a question about NEdit, it is one about Cygwin!)
and everything works fine, except for the shell commands.
I turned NEdit's shell to tcsh (standard is csh) and I can start any application
with it (even Windows applications).
The problem is, that NEdit does not see when the called application terminates,
so it never returns from the shell command!
Now one has to know how NEdit works internally.
I learned the following from NEdit's mailing list:
> I went through this loop once many moons ago, investigating process IDs
> and process group IDs. That was a blind alley.
>
> The solution is to close all I/O descriptors that NEdit knows about:
> stdin, stdout and stderr. The easiest way to do that is to reattach
> them to /dev/null. The actual program of interest can then be run
> without NEdit knowing about it.
So NEdit only looks at stdin, stdout and stderr to decide whether
the process is still running! For example:
> Many people have asked about starting things like TeX/DVI
> viewers from NEdit and the answer is simple: instead of writing a
> shell command line like
> view % &
> you should write (csh)
> view % & < /dev/null >& /dev/null
> In the first case, although the calling shell dies, the view program
> still has the I/O descriptors open; NEdit sees that they are still open
> and decides that the shell call is still running. Only when the view
> program exits does NEdit see that there is nothing using the standard
> I/O streams. Of course, the view program, being typically an X program,
> doesn't care about its standard I/O, but it still has them attached,
> inherited from its (dearly departed) parent shell process.
>
> In the second case, the shell closes the view program's standard I/O
> streams before the view program is actually called, so it is never
> actually attached to the streams NEdit knows about and waits for. So
> as soon as the invoking shell dies, NEdit sees that nobody is still
> using the standard streams that it supplies, and decides that the called
> program has terminated.
The above /dev/null trick doesn't work for Cygwin (invalid null command).
But, anyway, my problem is, that NEdit doesn't return, even when the
called application is terminated.
Why doesn't the above algorithm (looking at the I/O descriptors) work for Cygwin?
Are there any workarounds?
Any insight is appreciated!
Thanks!
Joerg
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -