Path: utzoo!attcan!uunet!lll-winken!uwm.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!convex.UUCP!root From: root@convex.UUCP (Superuser) Newsgroups: comp.windows.x Subject: Lost mail for you Message-ID: <9006071736.AA16214@sushi> Date: 7 Jun 90 17:36:07 GMT Sender: root@athena.mit.edu (Wizard A. Root) Organization: The Internet Lines: 75 From pescadero.stanford.edu!expo.lcs.mit.edu!xpert-mailer Fri Jun 1 21:05:44 1990 remote from convex Received: by sushi (5.51/7.0) id AA05942; Fri, 1 Jun 90 21:05:44 CDT Received: by convex.COM (5.51/4.7) id AA08187; Fri, 1 Jun 90 21:05:39 CDT Received: from Erebus.Stanford.EDU by uxc.cso.uiuc.edu with SMTP (5.62+/IDA-1.2.8-900601) id AA02264 (for salevin%drlc1.UUCP@convex.com); Fri, 1 Jun 90 21:01:19 -0500 Received: from Hanauma.Stanford.EDU by erebus.Stanford.EDU with TCP; Fri, 1 Jun 90 19:03:31 PDT Received: by hanauma.stanford.edu (5.51/7.0) id AA29758; Fri, 1 Jun 90 19:01:08 PDT Received: from EXPO.LCS.MIT.EDU by Pescadero.Stanford.EDU (5.59/25-eef) id AA24841; Fri, 1 Jun 90 18:59:52 PDT Received: by expo.lcs.mit.edu; Fri, 1 Jun 90 16:07:23 EDT Received: from bloom-beacon.MIT.EDU by expo.lcs.mit.edu; Fri, 1 Jun 90 16:07:06 EDT Received: by bloom-beacon.MIT.EDU (5.61/25-eef) id AA06973; Fri, 1 Jun 90 15:28:06 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for xpert@expo.lcs.mit.edu (xpert@expo.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 1 Jun 90 18:45:00 GMT From: convex!THINK.COM!barmar (Barry Margolin) Subject: Management of '/dev/console' on a computer server for X terminals Message-Id: <19900601184505.8.BARMAR@OCCAM.THINK.COM> References: <9006011800.AA12409@gateway.think.com> Sender: convex!expo.lcs.mit.edu!xpert-request To: xpert@expo.lcs.mit.edu 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