In article <20020616081513.22B7411138@www.netbsd.org>,
	auto92089@hushmail.com writes:
>>Release:        NetBSD-1.4.2

> If you have a script which exits after starting X (which prevents
> people from control-C'ing startx to grab your shell) then I believe
> the getty on that virtual terminal and X (also apparently started on
> that virtual terminal) fight for input.

Of course they will. What do you think should happen?

If you use:

	exec startx >& startx.log	# csh or tcsh

or

	exec startx > startx.log 2>&1	# sh, ksh, bash

The getty won't restart until you exit X, and if anyone kills the Xserver,
all they'll get is a login prompt. (I prefer to use "xdm", myself.)

> On your first virtual terminal, startx & exit.  This brings up X and
> you should be experiencing the getty and X fighting for input, causing
> keystrokes to be lost.  Curiously, if you switch to your second virtual
> terminal, it contains part of the output from the first virtual
> terminal.  Very weird.

That could be a bug in wscons. I see you're running 1.4.2. NetBSD 1.4.2
was released over *two* *years* *ago*, and it isn't even the latest release
on the netbsd-1-4 branch! There have been a lot of changes since then.
Could you try to reproduce the problem with a newer release, 1.5.2 at least,
or one of the betas/release candidates for 1.6 or 1.5.3?

-- 
Frederick