Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!dali!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!THINK.COM!barmar
From: barmar@THINK.COM (Barry Margolin)
Newsgroups: comp.windows.x
Subject: Management of '/dev/console' on a computer server for X terminals
Message-ID: <19900601184505.8.BARMAR@OCCAM.THINK.COM>
Date: 1 Jun 90 18:45:00 GMT
References: <9006011800.AA12409@gateway.think.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 48


    Date: Fri, 01 Jun 1990 13:56 EDT
    From: lwv27%cas.BITNET%CAS.BITNET@CORNELLC.cit.cornell.edu

    The difference is that xterm supports the -C option of tearing away the
    console from who ever had it last.  

xterm -C should only be used by someone starting up an X server on the
physical console.  Its purpose is to redirect console output to a
window so that it doesn't splat across the raw console.  I don't think
it affects console input at all, though.

I think it would even be reasonable for xterm -C to check whether it's
being used on the console.  Random X users shouldn't be allowed to steal
away the console.  The superuser should be allowed to bypass the check,
though; this way, if the system manager is using an X terminal he can
redirect console output to one of his xterms.

					An example of a program which uses
    console for input is FrameMaker, which in the case of one or two of its
    errors outputs a question and expects a response from the user.  

This is very surprising.  It really uses /dev/console rather than standard
input?  Thanks for warning me, as we are heavy X terminal users and
we're starting to use FrameMaker.  You should complain to Frame about
this.

								     Also, at
    least on my Sunview machine, a lot of errors from windows started up at
    login time or errors of NFS, wall output, etc. all are going to the console
    window.  Without any console, the X terminal will not know about these
    events.  With a console, the other users will not know about them.

Errors from windows started up at login time should go to the stderr of
the process that is starting up the windows, not to /dev/console.  At
our site, wall output goes to all xterm windows (I think xterm has to be
setuid root for this to work, so that it can write into /etc/utmp).  NFS
errors go to the stderr of the process getting the error and to the
console; the latter is for the benefit of the system manager.  This is
just like users on ASCII terminals -- why should X terminal users see
any more messages than ASCII terminal users?

Of course you should have a console on the system.  You need a console
in order to boot, run single user, run diagnostics, etc.  The console
could be a cheap ASCII terminal, though (although some of the newer Suns
cost *more* without a bitmap console).

                                                barmar