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
