les@chinet.chi.il.us (Leslie Mikesell) (11/19/88)
In article <144@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: > >Try some harder ones like programs doing direct video ram writes, Microsoft >Windows, Wordstar, WordPerfect, Lotus, Symphony and I have it from a >relatively reliable source that a VP/ix session will now run NOVELL client >with arbitrary ethernet cards! Wordperfect 5.0 seems to lose the ability to interpret the keyboard after displaying a directory (F5). The graphics work fine, though. Does anyone know the parameters to let dos under vp/ix talk to a network card? (I want to run as a client on an "old-style" starlan net and the unix software only supports "new-style starlan). Also, is there any real documentation on using the virtual terminals? It seems pretty silly to have to start a dos session just to get access to them. I've been playing with a script that starts shells connected to several of them. It seems to work to just: STTY=`stty -g` (stty $STTY; ksh -i) </dev/vt01 >/dev/vt01 2>/dev/vt02 & ..repeat for several vtnn's except that I end up connected to the last vt session that is created instead of returning to the one where the script started. After doing this I can use the alt-prtscrn <Fn> to jump to session n and things seem to work right although there is no utmp entry for the virtual sessions. Les Mikesell
fmcgee@cuuxb.ATT.COM (~XT4103000~Frank McGee~C23~M24~6326~) (11/23/88)
In article <6966@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <144@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: > >> >>Try some harder ones like programs doing direct video ram writes, Microsoft >>Windows, Wordstar, WordPerfect, Lotus, Symphony and I have it from a >>relatively reliable source that a VP/ix session will now run NOVELL client >>with arbitrary ethernet cards! > [.......] >Does anyone know the parameters to let dos under vp/ix talk to a network >card? (I want to run as a client on an "old-style" starlan net and the I'd sure like to know how they got the ethernet clients going under Simultask. There are hooks to provide access to hardware boards/devices without going through Unix (IEM and DDA) but from what I understand they shouldn't work in this case. The official stance on Simultask network connectivity is that the only connectivity is by using RFS, and that only allows read-write access; no true file sharing/serving or record/file locking. The redirector that comes with Simultask does not support any DOS NETBIOS calls. >Also, is there any real documentation on using the virtual terminals? Probably what you are looking for is the 'newvt' command. It creates another virtually terminal session. There's also something like a "vtgetty". My info indicates there should be man pages for these, but my documentation is still in a mass of about 10,000 uncolated pages (:-). Hope this helps you out, Frank McGee Tier 3 Indirect Channel Sales Support attmail!fmcgee -- Frank McGee Tier 3 Indirect Channel Sales Support attmail!fmcgee
clewis@ecicrl.UUCP (Chris Lewis) (11/24/88)
In article <6966@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >Also, is there any real documentation on using the virtual terminals? >It seems pretty silly to have to start a dos session just to get access >to them. Are you running Xenix or UNIX? You're supposed to have getty's sitting on the vt's (via UNIX inittab). Take a look at /etc/gettydefs to find the definitions that have the "VT0x!login" prompts. If you're using a reasonably recent version of 386/ix or AT&T UNIX (I think) there is a sysadm menu to change the number of virtual terminals. -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)
bill@ssbn.WLK.COM (Bill Kennedy) (11/25/88)
In article <152@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: |In article <6966@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: |>Also, is there any real documentation on using the virtual terminals? |>It seems pretty silly to have to start a dos session just to get access |>to them. | |Are you running Xenix or UNIX? | |You're supposed to have getty's sitting on the vt's (via UNIX inittab). |Take a look at /etc/gettydefs to find the definitions that have the |"VT0x!login" prompts. If you're using a reasonably recent version of |386/ix or AT&T UNIX (I think) there is a sysadm menu to change the |number of virtual terminals. |-- |Chris Lewis, Markham, Ontario, Canada I think that Chris is wrong about AT&T UNIX, but I hope he isn't. I have the gettydefs for virtual terminals but I can't get a getty to run on them. I am able to use them under VP/ix out of DOS, but that's only after getting DOS going. Is Chris correct? Is there some way to get virtual terminals going on the console in AT&T 386 UNIX? If so, please post or email, that's about my only real beef with the product. -- Bill Kennedy usenet {killer,att,rutgers,sun!daver,uunet!bigtex}!ssbn!bill internet bill@ssbn.WLK.COM
tgr@picuxa.UUCP (Dr. Emilio Lizardo) (11/28/88)
In article <261@ssbn.WLK.COM>, bill@ssbn.WLK.COM (Bill Kennedy) writes: > I think that Chris is wrong about AT&T UNIX, but I hope he isn't. I have > the gettydefs for virtual terminals but I can't get a getty to run on > them. I am able to use them under VP/ix out of DOS, but that's only after > getting DOS going. > > Is Chris correct? Is there some way to get virtual terminals going on the > console in AT&T 386 UNIX? If so, please post or email, that's about my > only real beef with the product. In AT&T UNIX System V Release 3.2 there is a virtual terminal manager: /usr/bin/vtlmgr. When invokes, it execs itself into the background so that init becomes its parent. It allows the console user to access the virtual terminals (/dev/vtnn) by pressing "<ctrl>-<sysreq>" followed by a function key (on my system, there are seven vt devices, so only F1-F7 are active; I don't know if it's possible to have more). The vtlmgr will not execute on remote terminals. It also will not execute itself twice (i.e., once it's running, further invocations will give an error message about opening the vtmon device). The process dies when it's invoker dies (i.e, it's not a daemon). The virtual terminal manager apparently does not exist in SVR3.1 for 386; if it is there it's under a different name. -- Tom Gillespie |AT&T/EDS Product Marketing Technical Center UUCP: att!picuxa!tgr |299 Jefferson Rd. Parsippany NJ 07054 ATTMAIL: tgillespie |(201) 952-1178 "Don't take life so serious ... it ain't nohow permanent." -- Walt Kelly
tgr@picuxa.UUCP (Dr. Emilio Lizardo) (11/28/88)
A correction on my earlier posting about virtual terminals -- I said that the vtlmgr: > ... allows the console user to access the virtual >terminals (/dev/vtnn) by pressing "<ctrl>-<sysreq>" followed by a function >key (on my system, there are seven vt devices, so only F1-F7 are active; >I don't know if it's possible to have more). I meant to specify the key sequence as "<alt>-<sysreq>" ------------ In a related article, Bill Kennedy (bill@ssbn.WLK.COM) writes: > ...You can have 7 of them, just fire up a >getty on /dev/vt0n where n is the number of what you want. Also use the >virtcon gettydef and you're on your way. Alt-SysReq-Fn will get you to >that virtual console and Alt-SysReq-F8 will get you back to the "real" >console. This is true for SVR 3.1 for 6386; it is not true for SVR3.2. First of all, there is an "/etc/vtgetty" running on console instead of /etc/getty. If you try to add more such vtgettys to /etc/inittab, you will not have access to them -- you get an error to the effect that /dev/vt00 is still open and must be closed first. You can add /etc/getty processes for the virtual terminals, but using <alt><sysreq>F8 will not return you to the console session; perhaps a different keystroke sequence works (I solved it by su'ing and removing the vt01 entry from inittab, and control returned to my console session as soon as I logged out). Also, my system did not have a "virtcon" gettydef already defined. Personally, I think the SVR3.2 implementation is somewhat better, since it's spawning a shell on the virtual terminal instead of a getty, so that you don't have to log in again. Virtual terminal shells are spawned only as they are used, so you don't have extra processes being run by init. However, the vtlmgr apparently spawns the shells in a linear fashion, as if each virtual terminal shell were a child of the invoking process (in fact, the vtlmgr is the parent to all vt shells). Thus, the only way to get back to console without terminating all of the virtual terminals is to use <alt><sysreq>Fn, where n is the number of the vitrual terminal that was invoked first. Terminating that virtual session will return control to the console without killing the other vt processes. -- Tom Gillespie |AT&T/EDS Product Marketing Technical Center UUCP: att!picuxa!tgr |299 Jefferson Rd. Parsippany NJ 07054 ATTMAIL: tgillespie |(201) 952-1178 "Don't take life so serious ... it ain't nohow permanent." -- Walt Kelly
les@chinet.chi.il.us (Leslie Mikesell) (12/02/88)
In article <709@picuxa.UUCP> tgr@picuxa.UUCP (Dr. Emilio Lizardo) writes: > You can add /etc/getty processes for the virtual terminals, >but using <alt><sysreq>F8 will not return you to the console session; perhaps >a different keystroke sequence works It is <alt><sysreq><h> to go to the console but I still haven't found any real documentation for the vt devices. What I want to do is automatically start several jobs on the vt's when I log in at the console (i.e. I don't want to log in to each one). Starting a background shell with simple redirection almost works but it doesn't connect the process group to the vt (so no interrupt signal). Using setpgrp disconnects the session from the console but it is still not connected to vt. Also, now that I have run vtlmgr the <alt><M><U> from a dos session will not give me a new unix session even though I have logged out killing the previously started vtlmgr (this still works for root, though). A window manager that would allow you to name the sessions would be nice, or perhaps GNU emacs could be taught how to use them. Les Mikesell