Re: Various starting X problems

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

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/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,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