This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: Fwd: Re: Various starting X problems
- From: luke dot kendall at cisra dot canon dot com dot au
- To: cygwin-xfree at cygwin dot com
- Date: Fri, 2 Apr 2004 18:02:02 +1000 (EST)
- Subject: Re: Fwd: Re: Various starting X problems
- Reply-to: cygwin-xfree at cygwin dot com
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