This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: request for new feature
On Mon, Aug 04, 2003 at 12:03:37PM -0400, Harold L Hunt II wrote:
>Alexander Gottwald wrote:
>
>>On Mon, 4 Aug 2003, Harold L Hunt II wrote:
>>
>>
>>>> /* we must build this string with information about mount points */
>>>> const char* command = "c:\\cygwin\\usr\\x11r6\\xterm.exe -display
>>>> :0.0";
>>>
>>>That line and comment are really the crux of my whole argument. It is
>>>simple to spawn a process. It is not necessarily so simple to use a
>>>non-hardcoded path to the executables
>>
>>
>>The code from cygpath has a conversion unix_path->windows_path.
>>
>
>No, I mean we have to find the path that XWin.exe was started from so
>that we can find xterm. We can't just hardcode c:\cygwin\usr\X11R6\bin.
Why is this an issue? Why can't you just add "/usr/X11R6/bin" to your
PATH? There is no need to convert pathnames to windows format. Cygwin
does that for you.
>>>, nor is it so easy to ensure that
>>>zombie consoles are not created in the process.
>>
>>
>>They'll die when the xserver kills the connection. Otoh there are a lot of
>>options (esp. the PROCESS_GROUP things) which control such process
>>inheritance.
>>
>
>That's not what I meant. What I meant was we don't want 10 little
>console windows, one for each of the xterms that we started up. Thus,
>we may either need to call 'run.exe', or we may need to do what
>'run.exe' does internally.
If xwin has any kind of console attached to it, you won't see the
extra consoles windows. There is code in cygwin (fhandler_tty.cc) for
creating invisible console windows on NT, fwiw.
>>Lets see if someone builds these (in my opinion useless) things.
>
>I think that having a non-hardcoded path and no useless console windows
>are essential. I wouldn't distribute a version that didn't have those
>two things.
I agree that these are two crucial goals for this. It should be flexible
and it shouldn't have those annoying console popups. Not that my opinion
matters in this case...
cgf