Re: Fwd: Re: Various starting X problems

[luke dot kendall at cisra dot canon dot com dot au]

On  1 Apr, Harold L Hunt II wrote:
>  Luke,
>  
>  
>  
>  luke.kendall@cisra.canon.com.au wrote:
>  >>>    cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory
>  >>>    xinit:  No such file or directory (errno 2):  no program named "/usr/X11R6/bin/xterm" in PATH
>  >>
>  >> 
>  >> Something else must be wrong with your path.
> > 
> > 
> > I don't think so.  FWIW, here is my full and ugly PATH, wrapped for
> > easy reading but no other changes:
>  
>  Oh no, once again I am right on this one... read on for a full 
>  explanation of what you need to tell us in the future when you have such 
>  problems.

Sorry, there was no way that you could know that the startx.bat script
wsa *not* involved; it's only used from the desktop shortcut.  It lives
in "/", and that's not on my path.

> > I definitely have a custom .xinitrc file.  In fact part of our site
> > post-install process was to create a default one, since initially
> > Cygwin's XFree didn't include it.  I hadn't realised it was colliding
> > with one from Cygwin.  Our standard site post-install creates the
> > ~/.xinitrc.  Sounds like I'd better try to back that out.
>  
>  /etc/X11/xinit/xinitrc can be copied to ~/.xinitrc, but your copy looks 
>  pretty close to stock except for the window manager that you are running.

Makes sense.  .xinitrc is just vanilla X stuff.

> > How much does Cygwin's XFree depend on the (traditionally)
> > user-controlled .xinitrc file, to work properly?  Does it also depend
> > on specific Cygwin things in ~/.Xresources?
>  
>  Not sure what you are asking here... I don't think the things you are 
>  worried about matter in this case.

Well, if it doesn't matter whether I'm using mine or using the default
one from the XFree install, then there's nothing to worry about.


>  >> I think you can override the defaultserverargs in your .xinitrc so that 
>  >> you could have a .xinitrc that both starts its own wm and prevents 
>  >> startx from passing "-multiwindow" to XWin.exe.  I'm not an xinit/startx 
>  >> expert, so you'll have to look for docs on that elsewhere.
> > 
> > 
> > Are there any docs on -multiwindow and using the Windows desktop as
> > your window manager?

I gather that -multiwindow in effect includes a window manager, and
that's the main thing to know.


> > I tried startxwin.sh without a lot of joy.  I can't see where it gets
> > its starting set of windows, and I can't see how to start up any
> > windows conveniently either.  (Currently it has -multiwindow and
> > -clipboard hardwired in - it doesn't seem to do any argument
> > processing.)
> > 
> > I may change that and send you a revised one, if you'd be interested.
> > 
> > Perhaps my question is, why would anyone choose to run multiwindow
> > using the Windows desktop?  There seems to be no easy way to start X
> > applications, except presumably from the command line.
> > 
> > It doesn't seem to use .xinitrc how I'd expect.  Sure, if I add an
> > "exec wmaker" then it all fails because it thinks a window manager (the
> > Windows desktop) is running, and bails out.  But if instead I add an
> > xmessage "Quit X" at the end instead, that never appears.  I just end
> > up with the "console window" with yellow text on black background, and
> > an icon in the Windows tray, that I can use to exit X or unhide the
> > root window.
> > 
> > If I unhide the root window, then the X cursor disappears.  Nor can you
> > call up a root menu, since I suppose Windows doesn't understand that.
> > And I know of no way to get a root menu in the Windows + multiwindow
> > "environment" or mode.
> > 
> > Also, as I said, if I unhide the root window in this mode you can't
> > exit from X.  You can request to do so, but it doesn't exit until you
> > rehide the root window.  You can also exit from the taskbar icon if you
> > have the root window hidden, but not if the root window is displayed.
> > 
> > Hope this makes some sense, and/or is of some use!

You'll notice that all the above problems were with using your
startxwin.sh script.

>  
>  This looks fine to me.
>  
> > ----------------------- cygwin/startx.bat -------------------------
> > @echo off
> > 
> > rem	The D: gets replaced by the real Cygwin drive during installation:
> > C:
> > 
> > chdir \cygwin\bin
> > 
> > rem	For use with sample .profile: stop the exec in user's .profile for the
> > rem	case where we're really starting the X server.
> > set STARTX=df
> > 
> > rem
> > rem 	Comment out the -rootless line if you *do* want the whole X desktop.
> > rem	-multiwindow had both hopeless performance and inability to get
> > rem	character input into an rxvt or xterm window under WindowMaker.
> > rem
> > 
> > 	bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx"
> > rem	bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx -- -rootless"
> > rem	bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx -- -multiwindow"
> > 
> > pause
>  
>  Yeah, there is the money shot baby.  This whole time you've been using a 
>  poorly named file that you guys created on your own called "startx.bat", 
>  while we've been assuming that you've been reporting a legitimate 
>  problem with a file that we are distributing called "startx", living in 
>  /usr/X11R6/bin/startx.

Apologies for not making it clear that all those tests were using your
startx script, not my startx.bat (which is only used in a desktop
shortcut).  All the examples I gave were starting X from the bash
shell, so it was finding your startx script.  To confirm, I just did
some more little tests:


    $ /usr/X11R6/bin/startx --  -clipboard :0;  grep "/usr/X11R6/bin/X" /tmp/XWin.log
    XCOMM: not found
    XCOMM: not found

    cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory
    : illegal option -- t
    : illegal option -- r
    : illegal option -- a
    : illegal option -- d
    : illegal option -- i
    : illegal option -- t
    : illegal option -- i
    : illegal option -- o
    : illegal option -- n
    : illegal option -- a
    DISPLAY is :0
    xterm: unexpected handshake status 852034
    xterm: unexpected handshake status 4328344

    waiting for X server to shut down xterm:  fatal IO error 32 (Broken pipe) or KillClient on X server ":0.0"


    /usr/X11R6/bin/X :0 -clipboard :0 

The above worked fine; no WM of course.

I also discovered that a kind of dyslexia kept hitting me.  I realise
now that the very stupid and wrong thing that I often did, to provoke
the weird error message that fooled me for a long time:

    cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory
    xinit:  No such file or directory (errno 2):  no program named "/usr/X11R6/bin/xterm" in PATH

    Specify a program on the command line or make sure that /usr/X11R6/bin
    is in your path.


    waiting for X server to shut down .

    /usr/X11R6/bin/X :0 

.... was that I put the -- in the wrong place, so I was trying to pass
-multiwindow or -clipboard to god knows what.  I didn't expect the
error message about there being no /usr/X11R6/bin/xterm (and I'm
*still* surprised and confused that xterm has been moved from that
directory to /usr/bin.)


Anyway, if you run up X using your startx and specify -multiwindow,
then you get all the problems I described above if you unhide the root
window:

> > If I unhide the root window, then the X cursor disappears.  Nor can you
> > call up a root menu, since I suppose Windows doesn't understand that.
> > And I know of no way to get a root menu in the Windows + multiwindow
> > "environment" or mode.
> > 
> > Also, as I said, if I unhide the root window in this mode you can't
> > exit from X.  You can request to do so, but it doesn't exit until you
> > rehide the root window.  You can also exit from the taskbar icon if you
> > have the root window hidden, but not if the root window is displayed.

I suspect that this is not peculiar to me.  Please try it, and see if
you get the same problems.

>  Now that we know which script we are trying to fix (your startx.bat, not 
>  our startx shell script), there are two things that I see wrong:
>  
>  1) You should not need to set the PATH in the -c argument to bash.  You 
>  should have a file called /etc/profile.d/00XFree86-bin.sh that does this 
>  for you.  You can test this by removing your -c command altogether and 
>  observing that the PATH still has /usr/X11R6/bin in it.  I recommend 
>  removing your setting of the PATH unless you can prove that it does not 
>  work otherwise because it is likely to continue to cause confusion to 
>  anyone looking at in the future.

I see, that should work when bash is invoked with -login.  I agree,
that's a better way to do it.

>  2) We keep telling you to either edit /usr/X11R6/startx and change the line:
>  
>  defaultserverargs="-multiwindow -clipboard"
>  
>  to:
>  
>  defaultserverargs=""
>  
>  -or-, pass " -- :0" to startx.  I think there has been a lot of 
>  confusion here by your naming your batch file "startx.bat"... what you 
>  need to do in this case is edit your startx.bat and change the end of 
>  the line that reads "[...] startx" to be "[...] startx -- :0".  That 
>  will prevent -multiwindow from being passed by the defaultserverargs in 
>  /usr/X11R6/startx.

Well, my startx.bat has not been a factor in most of these tests I've
done.  I also observe that rather than exiting your startx script, it
looks like there's a way to override the defaults by using a
~/.xerverrc file.  I also agree that the "-- :0" to startx avoids the
problems I initially had.  But I'm just trying to pass on information
about the other problems that occur if you run in -multiwindow mode and
unhide the root window.

>  Okay, this is really getting into the nitty-gritty now about a problem 
>  with a script that you guys wrote, so I can't really spend anymore time 
>  on this issue.  You'll either have to look up generic resources on how 
>  to write proper shell scripts, batch files, and use xinit, or you'll 
>  have to help that someone else here helps you.  Sorry I can't do anymore.

I'd be highly embarrassed if the problems were caused by my batch
script, and I'd been wasting all your times.  I don't think it's been
involved, except that I may have mentioned other problems occuring when
starting X from the desktop shortcut that does use my startx.bat file.

Anyway, if you could have a quick try of the problems I've reported (it
should only take a minute: start in multiwindow mode and then unhide
the desktop via the tray icon), I hope you'll see I've not been wasting
all your times.

Regards,

luke