Re: Various starting X problems

[Harold L Hunt II <huntharo at msu dot edu>]

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 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?

It wasn't a change... the "xterm" package has always been this way since 
its inception a couple weeks ago.

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.

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

Still don't like that approach... it makes scripts that are dependent 
upon the setup of a machine at one point in time.  I can just see the 
complaints rolling in when users cut d:\cygwin and paste it to 
c:\cygwin, fix their mount points, and see that "X fails to start".

The reason I wrote a find_cygwin utility was because the assumption was 
that you don't know where cygwin1.dll is, nor do you know where cygpath 
is, not do I want the utility to be dependent upon any Cygwin utilities 
at all.  Of course, it isn't totally finished and probably never will 
be, but it was satisfying to see a 34 KiB program that could answer my 
question.

Another thing that the utility would be useful for is for launching 
programs from the start menu... if the Cygwin mount points change, all 
of the menu links are invalidated because cygwin1.dll can't be found, 
nor can anything else.  With a utility like find_cygwin you can have it 
look up where cygwin1.dll is via the mount points in the registry, then 
set the path to include that directory.  Course, this sort of doesn't 
work because batch files suck.

> > > 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.

Yup, it seems time to do this.

Harold