On Thu, 1 Apr 2004, Harold L Hunt II wrote (irrelevant parts snipped): > Phil Betts wrote: > > > Luke said: > > > >>>In my .xinitrc I *don't* have an explicit path for xterm. However, I > >>>see xterm has moved from /usr/X11R6/bin to /usr/bin! Did many other > > > > Slightly OT: I noticed that the start menu entry for xterm no longer > > works. Entering the command from the shortcut directly into the cmd.exe > > shell returns without an error or any output (that I can find). From > > bash, the command works fine. The other shortcuts that I've tried > > (e.g.. xcalc) all worked, so there is presumably something unusual about > > the way that xterm starts that causes a silent exit when started from a > > vanilla DOS/Windows shell. My guess is that it's relying on some env > > var. > > I'm aware of this. I don't remember the exact details, but there is a > sort of Catch-22 situation for setting the "start in" folder for the > xterm shortcut; neither '/usr/bin' nor '/usr/X11R6/bin' work for > different reasons. Furthermore, I believe that the script that creates > the shortcuts needs to be modified to be able to support shortcuts to > programs that live in /usr/bin. You'll notice that the emacs shortcut > also does not work for the same reason. > > I don't have time to fix this. I would appreciate it if someone else > would grab the -src package for X-start-menu-icons via setup.exe and > work on fixing it; I don't want a half-assed untested patch either, I > want one that has been thoroughly tested (you know, tough stuff like > clicking at least one of the tree classes of shortcuts: /usr/bin X > programs, /usr/X11R6/bin X programs, and /usr/X11R6/bin terminal > programs) since the sort of changes required may break the other links > that the scripts create (this is part of the Catch-22 I was talking about).
I don't recall any discussion or a heads-up that xterm now resides in /usr/bin... Any particular reason for this decision? > I wrote a short utility called "find_cygwin" using Open Watcom but I > haven't finished it yet. The problems I ran into were that I could get > the paths I needed, but exposing them to the batch file as a variable of > some sort was darn near impossible. How about the "macro replace in a postinstall script" approach I suggested earlier? Also, postinstall scripts already run *in* Cygwin, so there should be no reason to detect it, right? Just use "cygpath"... > > If you'd be interested in a unified approach, where the .bat just runs > > bash -c startxwin.sh (which will probably in turn be just a wrapper for > > startx) I might be able to make time for this. > > Yes, I think that may be the way to go at this point since we are > starting to waste a lot of cycles trying to do things in batch files > that are easily supported in shell scripts using *nix-style utilities. Perhaps you're right. As long as you run "bash --login -c ...", so that the PATH is set properly. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton