RE: Various starting X problems

["Phil Betts" <Phil dot Betts at heis dot co dot uk>]

Hi Harold,

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


I've just cracked this on my PC - it was a side effect of moving /usr
onto
my D: drive.  PATH under cmd.exe still had C:\cygwin\usr\X11R6\bin
which meant that xterm couldn't link with cygX11-6.dll.  This only
became
an issue once xterm moved to /usr/bin.

That point aside, is it not safer to work with /bin instead of /usr/bin
?
After all, that is where the files are really located:
  $ cygpath -w /usr/bin
  C:\cygwin\bin
On my PC, there is no "bin" in the usr directory so .bat files don't
stand a chance of finding anything in there!

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

If somebody does have time, I guess it's safest to assume (or insist)
that users have the result of "cygpath -w /bin" in their Windows PATH,
but
not necessarily /usr/X11R6/bin.  It would therefore work if the shortcut
starts in /usr/X11R6/bin.  This WFM:

  Target: D:\cygwin\usr\X11R6\bin\run.exe xterm -display 127.0.0.1:0.0
  Start in: D:\cygwin\usr\X11R6\bin

Obviously the "D:\cygwin\usr\X11R6\bin" part needs to be worked out
at installation time.

There does appear to be a problem with run.exe.  If the target program
can be found, but fails to link, the error is silently swept under the
carpet rather than passing on the message to the user.  To reproduce:
* start a CMD shell
* set PATH=<everywhere except /usr/X11R6/bin>
* cd to where your /bin lives
* type "xterm"
* you should get a dialog "xterm.exe - Unable To Locate DLL" with
  enough information to let you track down the problem
* now type <full path to run.exe> xterm
* result: no dialog, no error messages, no xterm.

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

Exactly!

>Give it a try.  Download the X-startup-scripts -src package via 

I'll see what I can come up with.  I've got looming deadlines at work
and I've only got flavours of Linux at home so don't hold your breath...

>I wouldn't go for the gold yet... just make a batch file that runs the 
>shell script first so that people can still create Windows shortcuts to

>the batch file, then we can go from there.

OK.  That's what I had in mind anyway.

>> There was mention a while ago of making multiwindow a standalone
window
>> manager.  Has anything been done in this direction?  <snip>
> 
>This isn't really a viable option at this time.  Splitting the window 

Pity, but not a problem.

>What I would rather see is some very minor tweaks (I have been thinking

>about doing these myself) that let the mutli-window window manager 
>silently exit without causing a crash if another window manager is 
>detected.  In fact, I would also like to create another dialog box that

>lets you check boxes to enable and disable -multiwindow and -clipboard 
>during the current session.  The first thing this will require a is a 
>continuation of the cleanup that I have been doing to the shutdown 
>process for the -clipboard code and a cleanup of the shutdown process 
>for the -multiwindow code.

This sounds like a reasonable plan.  When I used to run fvwm at home,
the
system menu had entries for switching to twm, mwm etc.  This, I guess,
just forked a non-window-manager process to perform the switch then
exited
(if you tried to switch to a non-existant or broken WM, you ended up
with
no WM)

You'd need to be careful though.  Say the user starts X without
multiwindow, running an external WM at the end of their ~/.xinitrc.  You
wouldn't want to kill their WM process if the user tried to switch to
multiwindow or some other WM because that would end their X session.
In effect, what you need is a way to coerce the running WM to use one of
the execxx variants to start the new WM so that the WM PID never dies.
This is certainly not trivial!

An easier alternative would be to have a small wrapper program, say
runwm,
whose sole job would be to keep a WM going.  The ~/.xinitrc would then
end
with something like:

  exec runwm wmaker

Killing the wmaker process could either restart wmaker, or perhaps fall
back to multiwindow mode.  Further attempts to run runwm e.g. "runwm
fvwm", would communicate with the already running process which would
kill
wmaker then start fvwm.

>Happy coding,

Is there any other kind? ;-)

Phil


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************