lwv27@cas.BITNET (05/30/90)
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! -- Larry W. Virden Business: UUCP: osu-cis!chemabs!lwv27 INET: lwv27%cas.BITNET@CUNYVM.CUNY.Edu Personal: 674 Falls Place, Reynoldsburg,OH 43068-1614 Proline: lvirden@pro-tcc.cts.com America Online: lvirden CIS: [75046,606]
barmar@think.com (Barry Margolin) (05/31/90)
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
barmar@THINK.COM (Barry Margolin) (06/02/90)
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).
barmarkucharsk@number6.Solbourne.COM (William Kucharski) (06/04/90)
In article <19900601184505.8.BARMAR@OCCAM.THINK.COM> barmar@THINK.COM (Barry Margolin) writes: >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. Alas, it does on SunOS; whatever pty gets console output (via the TIOCCONS ioctl) gets console input as well; I'll leave the drawbacks to this approach as an exercise for the reader :-) -- =============================================================================== | Internet: kucharsk@Solbourne.COM | William Kucharski | | uucp: ...!{boulder,sun,uunet}!stan!kucharsk | Solbourne Computer, Inc. | = The opinions above are mine alone and NOT those of Solbourne Computer, Inc. =
pjb@frame.com (Paul Bailey) (06/11/90)
In article <9006071736.AA16214@sushi>, root@convex.UUCP (Superuser) writes: > 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. > This is very surprising, because it's not true. FrameMaker for X11 does not send any messages to the console window. FrameMaker 1.3X is launched from its own xterm (called fmconsole), and messages are logged in that window. Starting FrameMaker using the -noconsole option causes all messages to go to the window where FrameMaker is started. Also, FrameMaker never expects any input to any messages displayed in the xterm. FrameMaker only accepts input via dialog boxes. Paul J. Bailey X Projects Group Leader Frame Technology Corp. 1010 Rincon Circle, San Jose, Ca. 95131 Domain: pjb@frame.com (408) 922-2778 UUCP: {ames,adobe,hplabs,riacs,sun,vsi1}!frame!pjb