On Fri, 2 Apr 2004, Harold L Hunt II wrote: > Igor Pechtchanski wrote: > > Harold, > > > > On Thu, 1 Apr 2004, Harold L Hunt II wrote: > > > >>Igor, > >> > >>Igor Pechtchanski wrote: > >> > >>>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 recall any discussion or a heads-up that xterm now resides in > >>>/usr/bin... Any particular reason for this decision? > >> > >>It wasn't a change... the "xterm" package has always been this way since > >>its inception a couple weeks ago. > > > > It was a change from the users' point of view. Their xterm used to be in > > /usr/X11R6/bin, and now it's in /usr/bin all of a sudden. The fact that > > it also moved into a separate package is incidental. > > > >>Chris and I discussed on cygwin-apps that there was no reason to put new > >>X packages in /usr/X11R6 so I have not been doing this for most new X > >>packages; barring those that do broken things and need to be stuck in > >>/usr/X11R6, like libXft. > > > > For new packages -- sure, but moving something as fundamental as xterm is > > not something to be taken lightly. > > > > There *is* a reason to put X11 binaries (and especially libraries) in the > > same directory. The reason is Windows dynamic linking. By default, > > Windows apps look for DLLs in the current directory before looking in the > > PATH. So, for apps that are in /usr/X11R6/bin, all the X DLLs are found > > automatically. Once xterm moves into /usr/bin, either all the DLLs it > > requires should also move there, or /usr/X11R6/bin should be *added* to > > the PATH (it wasn't required before). > > > > Also, moving xterm to /usr/bin breaks all sorts of existing scripts (those > > that hardcode the path to it as /usr/X11R6/bin, because it's not usually > > in the Windows PATH by default). At the very least there should have been > > an announcement declaring in large friendly letters that xterm won't work > > anymore unless you (a) change all your scripts that expect to find it in > > /usr/X11R6/bin, and (b) add /usr/X11R6/bin to your Windows system path, > > otherwise the necessary DLLs won't be found. > > > > Frankly, I think that moving 1 app to /usr/bin doesn't solve the problem, > > it only creates more. If you want to be rid of /usr/X11R6/bin, first move > > all the libraries to /usr/bin, and then move all the apps in one fell > > swoop. Until then, you'll only be causing users unnecessary anguish'. > > Just my 2c. > > Well, then don't feel upset that I'm disregarding your 2c.
Harold, If I had a penny for every time my 2c was disregarded, I'd still be losing money... :-) > "[...] breaks all sorts of existing scripts [...]" is pretty hard to > believe since it took the collective mailing list two weeks to even > notice the move. > > Harold Well, people who run xterm from non-login shells will notice this as soon as they upgrade. Maybe they just haven't upgraded yet (I haven't), or I'm one of the very few who invoke X apps this way. FYI, it will break my scripts (embedded in a bunch of shortcuts, FWIW) as soon as I upgrade. To fix this, I plan to create a symlink to /usr/bin/xterm in /usr/X11R6/bin (a good compatibility measure in a postinstall script, BTW). This won't help the DLL loading issue, but that should be fixable by just adding "c:\cygwin\usr\X11R6\bin" to the PATH. 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