[comp.sys.att] VT Initialization

pjh@mccc.edu (me) (03/02/91)

My login shell is ksh and my .profile has SHELL=/bin/ksh.  However,
when I Alt-SysRq-Fx, I have to invoke ksh manually.  Is there a way to
get ksh to come up automatically?

Thanks,
Pete
-- 
Prof. Peter J. Holsberg      Mercer County Community College
Voice: 609-586-4800          Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh  1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu	     Trenton Computer Festival -- 4/20-21/91

les@chinet.chi.il.us (Leslie Mikesell) (03/06/91)

In article <1991Mar1.165607.10590@mccc.edu> pjh@mccc.edu (me) writes:

>My login shell is ksh and my .profile has SHELL=/bin/ksh.  However,
>when I Alt-SysRq-Fx, I have to invoke ksh manually.  Is there a way to

You need to edit /etc/default/login and add the line ALTSHELL=YES
to tell login that it is OK to put your real shell's name into
the environment instead of pretending it is something else.

Now what I'd like is a way to (a) automatically start up an assortment
of things on the different VT's when I log in, and (b) a way to
access them (saved screen and all) from a dial-up or network login.

Les Mikesell
  les@chinet.chi.il.us

tr@SAMADAMS.PRINCETON.EDU (Tom Reingold) (03/17/91)

In article <1991Mar05.175251.15013@chinet.chi.il.us>
les@chinet.chi.il.us (Leslie Mikesell) writes:

$ [...]
$ 
$ Now what I'd like is a way to (a) automatically start up an assortment
$ of things on the different VT's when I log in, and (b) a way to
$ access them (saved screen and all) from a dial-up or network login.

As for (a), why not check for the tty name in your ENV file and act
upon that?

As for (b), my strong suspicion is that VT's are made possible by a
device driver that reads the keyboard and writes the video board
directly.  Accessing them remotely would mean writing a replacement
device driver: difficult.  Maybe one day, someone will rewrite "screen"
to run under System V.  Maybe one day *I* will do it.  Well, by the
time I can get around to it, everyone will have windowing systems
running over packet switched networks so it we won't want VT's any
more.
--
        Tom Reingold
        tr@samadams.princeton.edu  OR  ...!princeton!samadams!tr
        "Warning: Do not drive with Auto-Shade in place.  Remove
        from windshield before starting ignition."

les@chinet.chi.il.us (Leslie Mikesell) (03/19/91)

In article <9103170740.AA03323@samadams.Princeton.EDU> tr@SAMADAMS.PRINCETON.EDU (Tom Reingold) writes:

>$ Now what I'd like is a way to (a) automatically start up an assortment
>$ of things on the different VT's when I log in, and (b) a way to
>$ access them (saved screen and all) from a dial-up or network login.

>As for (a), why not check for the tty name in your ENV file and act
>upon that?

The shells on the VT's don't start up until you access them with the
alt-sysrq-fkey sequence.  What I had in mind was firing up the remote
logins to several other machines on the VT's as soon as I log in on
the console, so that I would already be at (say) a display of mail
messages when I switch to a particular machine's corresponding VT.
It might be possible to start them up from the login shell, but
if you run "newvt" you don't come back, even if you try to put it
in the background.  Starting a shell with i/o redirected to the
/dev/vt's in the background almost works but not quite, even with
a setpgrp.

>As for (b), my strong suspicion is that VT's are made possible by a
>device driver that reads the keyboard and writes the video board
>directly.  Accessing them remotely would mean writing a replacement
>device driver: difficult.  Maybe one day, someone will rewrite "screen"
>to run under System V.  Maybe one day *I* will do it.  Well, by the
>time I can get around to it, everyone will have windowing systems
>running over packet switched networks so it we won't want VT's any
>more.

I suspect that they are closely tied to the '386 memory management
and just substitute a different chunk of RAM for the video board
when you switch out. Vp/ix already knows how connect a DOS session 
to a serial terminal, which is also most likely handled by the
'386 memory management providing a fake video RAM.  So, it should
just be a matter of hooking the pieces together.   

Les Mikesell
  les@chinet.chi.il.us