[Fwd: Updated: XFree86-xserv-4.3.0-48]
I forgot to mention that XF86Config support is disabled in this release. It may be possible to get XF86Config support building again, but Alexander recently added some command-line options that should be a useable replacement for most users. In addition, the keyboard autoconfiguration seems to be working for nearly all users, so there may be little need for re-enabling the XF86Config support ever. Harold
RE: errors when switching users (security hole?)
Alexander, dont you think startxwin.bat should exit if XWin fails to start ? This should be pretty easy to support in a batch file : start XWin -multiwindow if not errorlevel 0 goto badexit --- Kris Thielemans [EMAIL PROTECTED] a écrit : This is normal behaviour. well, I doubt that you would get your xterm on somebody else's screen on Linux, but I see what you mean. By the way, would it be a good idea to abort startxwin.bat when it didn't manage to remove .X11-unix? That way, at least the user could be warned she's doing something wrong. = Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) Say NO to software patents Dites NON aux brevets logiciels You believe it's the year 1984, when in fact, its closer to 21841984 / Matrix Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com
[rboulet: Man not finding pages]
- Forwarded message from Ross Boulet rboulet - From: Ross Boulet To: Cygwin Subject: Man not finding pages Date: Sat, 28 Feb 2004 16:06:22 -0600 I solved my own problem with man not finding pages but in doing the research on it, I found something I thought might be worthy of mentioning. From the message: http://www.cygwin.com/ml/cygwin/2002-04/msg00064.html I learned the a colon prefix to $MANPATH allows man to search its default paths in addition to what is specified in $MANPATH. The /etc/profile.d/openssl.sh script handles this ok. However, the /etc/profile.d/XFree86-man.sh does not handle it the same way. I had an empty $MANPATH (since corrected by a new /etc/profile script). The XFree86-man.sh ran first and found no $MANPATH and thus assigned /usr/X11R6/man (no colon prefix) to $MANPATH. Then openssl.sh appended :/usr/ssl/man. The absence of a leading colon caused man to not find the basic pages so that basic stuff like 'man ls' produced 'No manual entry for ls'. I would suggest the XFree86-man.sh script be modified to add a colon prefix to $MANPATH to be consistent with the openssl.sh treatment of an empty $MANPATH. My apologies if this should have been posted to the cygwin-xfree ML, but I thought it appropriate here because it affects more than X. Ross -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ - End forwarded message -
Re: errors when switching users (security hole?)
Sylvain Petreolle wrote: Alexander, dont you think startxwin.bat should exit if XWin fails to start ? This should be pretty easy to support in a batch file : start XWin -multiwindow if not errorlevel 0 goto badexit Won't work. start launches XWin, then returns to the batch shell immediately. So, the errorlevel is likely always 0 unless start can't find XWin.exe. You wouldn't have a trivial way to check if XWin.exe actually succeeded in initializing. Of course, I didn't read the earlier part of this thread, so maybe the idea is to determine only if start did not find XWin.exe, but I think the user gets a pretty reliable error message if that happens. Harold
Re: [rboulet: Man not finding pages]
Well I'll be dipped in shit. Ain't that the weirdest thing you ever heard of? Now I gotta go revert that script and put a proper note in there so that no one tries to fix it like I did. Harold Christopher Faylor wrote: - Forwarded message from Ross Boulet rboulet - From: Ross Boulet To: Cygwin Subject: Man not finding pages Date: Sat, 28 Feb 2004 16:06:22 -0600 I solved my own problem with man not finding pages but in doing the research on it, I found something I thought might be worthy of mentioning. From the message: http://www.cygwin.com/ml/cygwin/2002-04/msg00064.html I learned the a colon prefix to $MANPATH allows man to search its default paths in addition to what is specified in $MANPATH. The /etc/profile.d/openssl.sh script handles this ok. However, the /etc/profile.d/XFree86-man.sh does not handle it the same way. I had an empty $MANPATH (since corrected by a new /etc/profile script). The XFree86-man.sh ran first and found no $MANPATH and thus assigned /usr/X11R6/man (no colon prefix) to $MANPATH. Then openssl.sh appended :/usr/ssl/man. The absence of a leading colon caused man to not find the basic pages so that basic stuff like 'man ls' produced 'No manual entry for ls'. I would suggest the XFree86-man.sh script be modified to add a colon prefix to $MANPATH to be consistent with the openssl.sh treatment of an empty $MANPATH. My apologies if this should have been posted to the cygwin-xfree ML, but I thought it appropriate here because it affects more than X. Ross -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ - End forwarded message -
Re: reset/terminate problems; preventing multiple XWin instances
A few issues I've encountered with Cygwin/X 4.3.0-47: Issue #1: In multiwindow mode, XWin doesn't reset when the last client exists. Example: XWin :9 -terminate -multiwindow sleep 5; DISPLAY=:9 xhost XWin should terminate after 5 seconds, but it remains running. It isn't supposed to. Run 'twm' as your window manager and you will see that the X Server does not reset when the last non-window manager client exits; this is because the window manager itself is a client. Also, the whole reset functionality is pretty much pointless for X Server that run on top of other windowing systems, which is the case for Cygwin/X. The only time it makes sense to perform resets for Cygwin/X is when disconnecting from an Xdmcp session. I have been thinking about removing or disabling the reset functionality in most non-Xdmcp cases for XWin.exe. Issue #2: In the default mode, XWin sometimes terminates instead of resetting. Example: XWin :9 sleep 5; DISPLAY=:9 xhost; sleep 5; DISPLAY=:9 xhost XWin should reset after 5 seconds and again after 5 more seconds. The first reset goes well, but on the second reset XWin usually terminates. You get two resets tops, then it crashes. That is due to some generic bugs in the Xserver/dix/ and Xserver/os/ code that has been fixed in more recent source code trees. We are working on cutting a release from a newer tree, but it hasn't happened yet. Issue #3: Hoe does one write a batchfile that does open an xterm window; run XWin first if necessary? Being perhaps the most common usage case, such a batchfile should be bundled in the Cygwin/X package and mentioned in the documentation. While a nice idea, you cannot currently. It isn't that this has not been thought of previously, it is just that no one has the time to do such a thing. Note that /usr/X11R6/bin/startxwin.bat always runs a new instance of XWin, even if one is already running. This can result in inefficiency and confusion when the script is executed several times to open several xterm windows (a natural thing to do). It's made even worse by issue #1 above. Also, startxwin.bat doesn't use -clipboard. It is not a trivial thing to fix, and no one has asked for it previously. However, you may be in luck because this is one of the things that is needed for a side project I am working on. I think Takuma might have also been thinking about implementing this feature. Harold
Re: reset/terminate problems; preventing multiple XWin instances
On 2004-02-28 21:07, Harold L Hunt II wrote: In multiwindow mode, XWin doesn't reset when the last client exists. It isn't supposed to. Run 'twm' as your window manager and you will see that the X Server does not reset when the last non-window manager client exits; this is because the window manager itself is a client. ACK. I think this should be noted in the documentation -- I didn't expect the magical window manager to count as a client. As for preventing multiple instances of XWin, a kludgy way to do it is by checking if anyone is listening on the X server port, using NETSTAT. Example: -- @echo off rem Opens an xterm. Runs XWin first if needed. set CYGWIN_ROOT=c:\cygwin set DISPLAY_NUM=1 netstat -p tcp -a -n | %CYGWIN_ROOT%\bin\grep -E -q ^ +TCP +0\.0\.0\.0:600%DISPLAY_NUM% .* LISTENING set PATH=%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin set HOME= set DISPLAY=:%DISPLAY_NUM% if not errorlevel 1 goto GOTX start XWin %DISPLAY% -multiwindow -clipboard -dpi 96 -nowinkill :GOTX run xterm -ls -dpi 96 -- (Remove the linebreak from the the 'netstat' line above.) BTW, -nounixkill seems to to be broken (Ctrl-Alt-Backspace still terminates XWin). Eran
Re: reset/terminate problems; preventing multiple XWin instances
Eran, As for preventing multiple instances of XWin, a kludgy way to do it is by checking if anyone is listening on the X server port, using NETSTAT. Example: This feature is already implemented in my local tree (not port based but mutex based detection). It is in test and documentation process and I will commit it to the public CVS soon. BTW, -nounixkill seems to to be broken (Ctrl-Alt-Backspace still terminates XWin). Thank you for reporting. Takuma Murakami
Re: reset/terminate problems; preventing multiple XWin instances
Eran Tromer wrote: On 2004-02-28 21:07, Harold L Hunt II wrote: In multiwindow mode, XWin doesn't reset when the last client exists. It isn't supposed to. Run 'twm' as your window manager and you will see that the X Server does not reset when the last non-window manager client exits; this is because the window manager itself is a client. ACK. I think this should be noted in the documentation -- I didn't expect the magical window manager to count as a client. Well, it is a general sort of thing for all X Server based on the so called Sample Implementation that was made by X.Org years ago. It isn't really specific to Cygwin/X. Granted, it sometimes makes sense to describe general things in our documentation that get asked about a lot. However, it may not be worth documenting since I am thinking about possibly disabling the automatic resets in most cases. As for preventing multiple instances of XWin, a kludgy way to do it is by checking if anyone is listening on the X server port, using NETSTAT. Example: Well, that is certainly one way to do it, but we need a more general fix within XWin.exe itself that makes it automatically select an unused display number, verify that nothing is listening on that port already (some other application perhaps), then launch using that display number. Of course, this also means that we need an option that says tells XWin.exe not to spawn another instance if if finds one is already running for the current user. That way we can modify the XFree86-bin-icons package to automagically launch the X Server. Hmm... but that will get tricky if we allow for multiple user machines and multiple instances of XWin.exe per user... that would mean that we would have to have a way to find out which of the current user's instances was a non-Xdmcp instance and what its display number was. Yikes, this is starting to get complex. BTW, -nounixkill seems to to be broken (Ctrl-Alt-Backspace still terminates XWin). Better report that in another thread so that interested parties will see it. Harold
Re: reset/terminate problems; preventing multiple XWin instances
Takuma Murakami wrote: Eran, As for preventing multiple instances of XWin, a kludgy way to do it is by checking if anyone is listening on the X server port, using NETSTAT. Example: This feature is already implemented in my local tree (not port based but mutex based detection). It is in test and documentation process and I will commit it to the public CVS soon. It is at least a good feature to fail when another instance of XWin.exe is operating on the same display number. Your fix still allows running multiple instances like the following, right? XWin :0 -query foo_host XWin :1 -multiwindow XWin :2 -fullscreen ... As long as it allows the above and only fails if someone tries to do the following, then it will be fine: XWin :0 ... XWin :0 ... [should fail] XWin :0 ... [should fail] Harold
Re: [Fwd: Updated: XFree86-xserv-4.3.0-48]
Oh, I also forgot to mention that this is a test release, so I need people to report on how well it works before I can mark it a the current version. Harold
clipboard integration still failing
i've downloaded the latest X server, and clipboard integration is still failing for me, hanging my X application (xmh on a remote machine) as soon as i select something. if i don't use -clipboard, then xwinclip still works ok, with it's known problems. let me know if i can provide more info to anyone interested in tracking down the problem. i'm on win xp. mike __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools
