On 12/11/2009 23:09, Lothar Brendel wrote:
Jon TURNEY wrote:
[...]
Fortunately, the X server
binds it's socket pretty early in the startup, so this probably works
pretty well, but in theory at least there is still a possible timing
window in startxwin.bat.
Yep, and in my setup the X server *always* comes up too late.
So it perhaps be useful if checkX retried the XOpenDisplay()
periodically until the timeout was up (as xinit does)
In principle, the script calling checkX could do that, because
``checkX'' has return status 1 if it couldn't connect. But as I already
pointed out
(http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg19529.html)
``startxwin.bat'' uses ``run'' as a wrapper for ``checkX''. =>
Definitely no waiting and no passing on of the status of ``checkX'' to
%errorlevel%, as ``run'' immediately goes background (unless called from
an xterm, dunno why).
But why would you fix the timeout problem by doing some horrible horrible
iteration in the DOS batch script (horrible) (which would probably have to
busy-wait (also horrible) as there's no sleep command), when you can fix
checkX, which has the bonus of fixing other uses of it?
Since more people seem to have this problem (cf. also Olivia's post), I
repeat my question (essentially already posed by Ken Brown:
http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg19402.html): Why
using ``run'' at all? If we really need a wrapper (do we?) wouldn't
``sh'' be a better one?
I guess we use run for the reason run exists: to hide the console window,
which otherwise would be shown?
Perhaps if you look how startxwin.bat is started from the start menu shortcut,
(as 'run startxwin.bat') you can see why this might be useful?
To push this even further: Do we really need two *independent* scripts,
``starxwin.bat'' and ``starxwin.sh''? Why can't the former just delegate
to the latter?
Indeed. They are useless to me for starting the server and a continual source
of problems. I would be quite happy to just delete them completely. :-)
Looking forward to reading your patches to address any of these problems.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
