Whenever I start Cygwin's X server using the "XWin Server" link in my Start menu, or by running startxwin from a Cygwin shell, I automatically get an xterm window appearing, which I neither want nor need.
How do I avoid that?
(Question inspired by this comment by Stijn Vanpoucke over on Stack Overflow)
UPDATE: This answer is now out of date. For an up-to-date answer, see user551570's answer below.
From man startxwin:
If no specific client program is given on the command line,
startxwinwill look for a file in the user's home directory called.startxwinrcto run as a shell script to start up client programs. If no such file exists,startxwinwill use the following as a default:xterm -geometry +1+1 -n login -display :0
Thus, to avoid having any program start up when you start the X Server, you want a blank .startxwinrc file. Just run the following from a Cygwin prompt:
touch ~/.startxwinrc
It seems that startxwin's behavior has changed since @me_and originally answered the question, so simply creating an empty .startxwinrc in your home directory won't work anymore.
I found an answer here. In essence when the last command in .startxwinrc exits, the server will exit. If you want to prevent that, you can put this as the last line in your .startxwinrc:
sleep inf
This won't start any client programs, but will also prevent .startxwinrc from exiting.
As of November 2014, the latest versions of startxwin use xinit to start the Cygwin/X server, which is actually called XWin.exe. The process goes something like this:
startxwinstartxwin creates a new .Xauthority file and one called .serverauth.1234 (where 1234 changes each time you start X)startxwin sets up some client and server parametersstartxwin calls xinit with the client and server parameters, including some optional shell scripts and a reference to the auth file.xinit starts the X server, running some of the rc scriptsxinit starts the client (usually xterm) or client rc script. We want to avoid thisxinit shuts down the X server. If we avoid step 6, we also need to avoid thisIt is possible to run XWin.exe directly from within a Bash login shell, without the surrounding tasks that startxwin and xinit perform. The main advantage of this is that it behaves like we want: the X server starts and remains running. Unfortunately, since there is no .Xauthority file passed during startup, your X server would permit any local process to connect to it, which is insecure.
Fortunately it's xinit that does most of the stuff we don't want. There's a quick hack that bypasses xinit but keeps the remaining elements of startxwin that are related to the server itself.
TL;DR: In startxwin, there's a line near the bottom that reads:
eval xinit \"$client\" $clientargs -- \"$server\" $display $serverargs
Change that line to:
eval \"$server\" $display $serverargs
From now on, the startxwin script will call XWin.exe directly, rather than calling xinit. Obviously this will disable any client rc scripts, but we didn't want those in the first place. It also means that X will continue running without needing a client process to keep it alive (i.e. keep xinit from killing it).
I've made it a habit to start Cygwin X with startxwin(.exe). My .startxwinrc file reads as follows:
X :0 -rootless mrxvt -geometry +1+1 -n login -display :0 -tt ImTabbed
So far, it's worked. The only error I get concerns the display still being "open" by another X process. This error specifies a certain file the X server generates by default for every session. The Cygwin folks are aware that it doesn't get deleted when the session terminates.
So I wrote an alias to "cure" that:
alias freex='rm /tmp/.X0-lock'
I put the same line -- the part in between the quotes, at any rate -- in my .bashrc and .bash_profile files in case I should forget to do it myself.
HTH.
BZT
