/dev/vt0x, gettys to virtual terminals on AT&T 6386 WGS

Kurt Gollhardt kdg at nirvo.uucp
Thu Sep 7 17:14:32 AEST 1989

In article <273 at opel.UUCP> mikes at opel.UUCP (Mike Spindler) writes:
>We're running an AT&T 6386, Sys V 3.2, with the virtual console devices.
>...  The process starting in inittab does a system() call to 
>vtlmgr and starts another process, redirecting input and output
>to/from /dev/vt01.

Not necessary.  The vtlmgr program is strictly for interactive creation
of shells on new vts (via, by default, <alt><sysreq><function key>).  The
main virtual terminal functionality, including switching between (already
open) vts, is handled directly in the console driver.

>We then have the following scenario:
>	a. /dev/vt01 has a real-time process running in the foreground
>	b. /dev/console has a getty running
>The user can switch to the /dev/console getty by issuing a <alt><sysreq><h>
>and log in for an interactive session.

This scenario should still hold true w/o invoking vtlmgr from inittab.
One thing to watch out for, though: depending on exactly how your program
is set up, it may end up with /dev/console as its controlling tty (as
shown by "ps") instead of /dev/vt01, even though its input and output
(and don't forget stderr) are on /dev/vt01.

>Upon logging out, I'd like the console to revert back to the /dev/vt01
>display.  But... currently the vt driver sees the /dev/vt01 running
>and asks the user if they want to kill the virtual terminal /dev/vt01,
>they must answer yes to get out (even though this does not kill the
>/dev/vt01 process.)
>Question #1: Is there any way possible to bypass this interactive step?
>		The logged-in user doesn't own the process anyway!

This behavior (checking for other vts on logout) is controlled by the
/etc/vtgetty program.  If you want to disable it, just change vtgetty
to getty in inittab (and /etc/conf/cf.d/init.base).

>Question #2: Has anyone already worked out how to program function
>		keys to work in place of the <alt>-<sysreq>
>		combinations (eg. <alt>-<sysreq>-<f1> also maps to
>		simply <f12>)?

This is described in gory detail in KEYBOARD(7) in the User's/System
Administrator's Reference Manual.  For this particular example, you'd
use the KDSKBENT ioctl with:
	kb_table = K_NORMTAB	[ unshifted key ]
	kb_index = 88		[ scan code for <f12> key ]
	kb_value = K_VTF+1	[ vt switch to vt01 ]

>Question #3: Has anyone figured out how to start up processes
>		directly from inittab to a virtual terminal?  What would
>		really be ideal is to start processes or gettys like
>		we used to under Microport.

You *can* run getty on a virtual terminal.  This inittab line works just fine:

	v4:23:respawn:/etc/getty vt04 console

>		That is, it seems that the
>		virtual consoles used under 3.2 do not have the capability
> 		to be accessed directly by programs started from inittab.

ANY process anywhere can access a virtual console simply by opening it.  If
you're going to use it interactively, though, you do have worry about things
like controlling tty, process groups, and proper stty settings; but these
issues are the same for *any* device which is starting from an uninitialized

There *is* a program which handles all these setup issues: /usr/bin/newvt.
Usage: newvt [-e command] [-n vt number].  If you leave out the command, you
get an interactive shell.  If you leave out the vt number, you get the first
free vt.  However, newvt appears not to be useable from inittab, so it may
not help you with this specific problem.  (I think the reason for this may be
that newvt needs to know what tty (e.g. /dev/console) it was run from - for
reasons beyond the scope of this article - but when run from inittab, it
doesn't have a controlling tty.)

>		Running vtlmgr from inittab is equally dreadful.

Certainly is.  Isn't it great that you don't have to? :-)

Kurt Gollhardt                      \   Nirvonics, Inc. -- Plainfield, NJ
Kurt.Gollhardt at nirvo.uucp           /\     Software Design and Consulting
...!rutgers!nirvo!Kurt.Gollhardt   /  \
     "It's all about people; not you and me or him and her, but *us*."

More information about the Comp.unix.i386 mailing list