Various starting X problems

[Harold L Hunt II]

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.

"[...] 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