Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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)

share|improve this question

4 Answers 4

up vote 1 down vote accepted

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.

share|improve this answer

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, startxwin will look for a file in the user's home directory called .startxwinrc to run as a shell script to start up client programs. If no such file exists, startxwin will 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
share|improve this answer
    
This solution was good for a long time, but now with the last update it is not. Using an empty .startxwinrc results in the immediate disappearance of the X server. :-( –  Notinlist Jan 23 at 9:45
1  
@Notinlist So it does. That's a bit sad. I'll try and investigate and find a new solution; it appears the system is somewhat more complicated now, and I can't trivially work out how it's supposed to work… –  me_and Jan 23 at 11:54

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

share|improve this answer
    
This isn't really an answer to this question; with rewording it could be, but I think this would be better suited as a separate question and answer (as I did here) about handling the error you're seeing. You can then link to that question in the comments to this one. –  me_and Oct 3 '12 at 10:08

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:

  1. You call startxwin
  2. startxwin creates a new .Xauthority file and one called .serverauth.1234 (where 1234 changes each time you start X)
  3. startxwin sets up some client and server parameters
  4. startxwin calls xinit with the client and server parameters, including some optional shell scripts and a reference to the auth file.
  5. xinit starts the X server, running some of the rc scripts
  6. xinit starts the client (usually xterm) or client rc script. We want to avoid this
  7. When you close the client or the client rc script finishes, xinit shuts down the X server. If we avoid step 6, we also need to avoid this

It 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).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.