[quoted lines by Brian Tew on March 24, 2002, at 02:17]
>could you elaborate on that just a tad.
You can, somewhat simplistically, think of each virtual console as being the
root of an entirely different process tree. You're starting a shell in virtual
console 1 (by starting it from rc.local), and sending all of the output from
that sehll (and its descendant processes) to the VB2+. When you switch to a
different virtual console, the only process writing to the VB2+, i.e. that
first shell, is still running within virtual console 1.
>Why does this setup stop virtual consoles?
It doesn't stop them. It's just that the VB2+ is only ever going to show you
the output from virtual console 1.
There's another aspect to this whole issue. By running your shell from within
rc.local, you're not letting rc.local finish. By not letting rc.local finish,
you're not letting its entry within inittab finish. That, in turn, isn't
letting init get to the point where it processes the respawn entries. This has
the effect of not letting any of the expected login processes start.
You could solve this by placing your shell into the background, i.e. by putting
an ampersand at the end of the command line which invokes it, but you still
won't be able to use your VB2+ in any other virtual console. Doing this will
cause yet another problem, though, since the login process for virtual console
1 will also get started, and that'll mean that you'll have two processes, i.e.
your shell and login, both contending for the same device. There are two
solutions to this. One is to delete the getty entry for virtual console 1 from
your inittab. The other is to run your shell in a different virtual console.
You can do the latter with a command like the following:
open -c 12 -s -l bash
You don't need a trailing ampersand because, as long as you don't specify -w
(wait), open puts the requested command into the background on its own.
The "-c 12" option specifies which virtual console to use (in this example,
virtual console 12 would be used). Without it, the first free virtual console
is used and that's not what you want for at least two reasons. Firstly, you
don't want to get into a conflict with the getty entries in inittab. Secondly,
it's much easier for a blind user to not have the system make an unpredictable
decision.
The "-s" option causes the system to automatically switch to the selected
virtual console after the command has been startee.
The "-l" option causes the shell to be run as a login shell, which will allow
your login profile to be run.
After all of that, I'd better give you the real command you need. You need a
more complex command because you need to get the shell's output to the VB2+.
You can't specify the redirection on open's command line because open
arbitrarily attaches the shell's standard I/O streams to the selected virtual
console. What you need to do, therefore, is to use open to run a script rather
than bash itself, and have that script do all of the necessary preparation and
then invoke bash. If you do it this way, don't specify open's -l option, and,
from within your script, use bash's -login option.
>Is there
>any way to have virtual consoles output with no vt escape sequences?
Do you really want none at all, or does the VB2+ support VT100 sequences. For
none, set the environment variable TERM (uppercase) to dumb (lowercase). For
vt100 sequences, set TERM to vt100. Use the command:
export variable=value
e.g.
export TERM=dumb
>Also, I am working on the terminal emulation / vb questions you asked.
>I will get back to you on that.
The best solution is to develop a BRLTTY driver for your display. That way,
it'll be much easier for you. The more information you have, the easier it'll
be.
--
Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me
EMail: dave@mielke.cc | Canada K2A 1H7 | if you're concerned about Hell.
http://familyradio.com