Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.windows.x
Subject: Re: Management of '/dev/console' on a computer server for X terminals
Message-ID: <36944@think.Think.COM>
Date: 30 May 90 22:50:48 GMT
References: <9005301206.AA07318@jade.berkeley.edu>
Sender: news@Think.COM
Reply-To: barmar@nugodot.think.com (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 25

In article <9005301206.AA07318@jade.berkeley.edu> lwv27@cas.BITNET writes:
>How are folks using X terminals currently handling the 'ownership' of /dev/conso
>Since there are occasional programs which either write to the console (and at
>least one or two that I have seen which ask for INPUT from the console), it
>seems like this is going to be a problem for folks trying to run multiple X
>terminals off a common processor.  AND, if that machine is also being used
>for serial ASCII terminals as well, a 'real' console may be needed as well!

I don't think there's any big difference between X terminals and character
terminals in this regard.  You don't do anything to the ownership of
/dev/console when someone logs in on a character terminal, so why should an
X terminal be any different?  Console messages (e.g. from syslog) should
still go to the real console.  I don't know what kinds of programs would
ask for input directly from the console, though; on all our Unix systems
(SunOS and Ultrix) when the system finishes booting a getty is run on the
console.  Even if you do run something else on the console (perhaps a
special shell oriented towards operator duties) I don't see how X terminals
would impact on this.  And if a program does I/O directly to /dev/console
it presumably wants this to occur on the real console, not some random
user's terminal (X or otherwise).
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar