Re: Various starting X problems

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

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/
      |\      _,,,---,,_		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