re: virtual dumbness

re: virtual dumbness

[Brian Tew]

Nicholas suggested  this line:
S0:12345:respawn:/sbin/getty ttyS0 9600 vt100

Ok, I  put that in  inittab & took out my stuff from rc.local.
Now how do I get to this ttyS0 console?
I seem to have virtual consoles; they change with the f keys.
But none of them is S0 nor ttyS0.

re: virtual dumbness

[L. C. Robinson]

On Tue, 26 Mar 2002, Brian Tew wrote:

> Nicholas suggested  this line:
> S0:12345:respawn:/sbin/getty ttyS0 9600 vt100

Actually, this line is incomplete, and probably won't work
(unless the compiled in defaults help you).

> Ok, I  put that in  inittab & took out my stuff from rc.local.
> Now how do I get to this ttyS0 console?  I seem to have virtual
> consoles; they change with the f keys.  But none of them is S0
> nor ttyS0.

ttyS0 is the first general purpose serial port (also known, in
MS-DOS, as com1), and is technically not a "console", unless you
make it so (or even a terminal, unless so connected and
configured).  The "console" is actually a device in the /dev
directory "/dev/console" and is where all system (usually kernel)
messages are sent.  It is automatically associated with whatever
virtual terminal you happen to be using at the time, or certain
other things we won't get into now.  Technically, what you are
referring to, I think, are "terminals", and linux supports many
kinds, simultaneously: the text based virtual terminals that use
the PC monitor and keyboard (there can be up to 63 of these) are
only one of these types.  Sometimes we loosely refer to all these
PC video card-and-monitor based virtual terminals as the "the
console", and as noted, they all can get the console messages, so
I can see where there could be some confusion.  You can also hook
up separate hardware serial terminals to as many serial ports as
you can get for your machine -- perhaps some of them connected
through modems.  And some types of terminals are designed to come
from other machines through a network (usually ethernet).  A
linux machine can support hundreds of these at a time, with as
many users, but you should use the facilities and utilities
provided for this purpose, or you will have all kinds of
problems.  

Properly speaking, when you hook up a synth or other adaptive
device to a serial port, it is acting as a specialized hardware
serial terminal, and is configured similarly to glass crt display
type of serial terminal (these are always text only -- you
usually buy them second hand for, say, $35.00, at thrift stores,
computer recyclers, or swap meets these days).  These should
always be configured with a getty running on them, as noted at
the beginning of this message.

Perhaps you missed my earlier message where I gave complete
directions on how to set all this up right (there is more to it
than just a line in /etc/inittab)?  If so, just drop me a
personal note, and I will send you another copy.  Posting it
again would likely be an annoyance to the other people on the
list.

There likely should be a HOWTO to explain the very basics of
serial text terminals and multiuser systems to complete newbies.
Does anyone know of one?  Maybe a link to one could be added to
the blinux FAQ.

LCR

-- 
L. C. Robinson
reply to no_spam+munged_lcr@onewest.net.invalid

People buy MicroShaft for compatibility, but get incompatibility and
instability instead.  This is award winning "innovation".  Find
out how MS holds your data hostage with "The *Lens*"; see
"CyberSnare" at http://www.netaction.org/msoft/cybersnare.html

re: virtual dumbness

[Brian Tew]

I normally keep my TERM environment variable set to dumb.
But lynx doesn't know what dumb means.  It says, "your terminal type
is unknown; may I suggest vt100, Dave?"
I either have to go along with vt100 or try telepathy.

I didn't know about the scrollback deal.
I'll see if it makes any difference.~p

re: virtual dumbness

[Brian Tew]

The versabraille has no terminal emulation built in.
When i use lynx or other ncurses programs, all the escape sequences appear on the vb
right there mixed up with the text.  It's a mess.
I can read it, but I mostly use the -dump switch
and read the resulting file.

The vb also has some programable memory, and there is a piece of software
called cp to provide vt100 emulation.
But, it works very poorly.
It is so bad that I much prefer to read all the escape sequences.

What I would really like is to make lynx send me nothing but
the text from it's webpages and no escape sequences at all,
but I guess that is impossible.

re: virtual dumbness

[Dave Mielke]

[quoted lines by Brian Tew on March 25, 2002, at 01:20]

>What I would really like is to make lynx send me nothing but
>the text from it's webpages and no escape sequences at all,

Try setting TERM=dumb, and, in lynx's configuration file, specifying
ENABLE_SCROLLBACK:TRUE.

-- 
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

re: virtual dumbness

[Brian Tew]

Quoting David:
He can't use Linux's virtual consoles the way he's sending output to his VB2+.
He's starting a shell from rc.local.
unqoute.

David, could you elaborate on that just a tad.
Why does this setup stop virtual consoles?
Where might I put a redirection to /dev/ttyS0 so as to allow them?
Is there any way to have virtual consoles output with no vt escape sequences?

I am not married to this particular setup.
It's just the first thing we thought of.
I only started linux two weeks ago.

Also, I am working on the terminal emulation / vb questions you asked.
I will get back to you on that.

Thanks.

re: virtual dumbness

[Dave Mielke]

[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

re: virtual dumbness

[Nicolas Pitre]

On Mon, 25 Mar 2002, Dave Mielke wrote:

> 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+.

If I'm not mistaken, the VB2+ sits on a serial port.  That serial port is 
totally separae from virtual consoles.  The serial port can be a "console" 
of its own.  However, Linux presents a console abstraction for the 
computer's video output and keyboard input.  The fact that they are called 
virtual consoles is because the kernel fakles multiple console terminals but 
all multiplexed on the same screen and keyboard.

Therefore, if a process (or better yet a getty) is started on a serial port, 
then it is considered as yet another console separate from the others.  To 
multiplex multiple "consoles" over a serial port, then the only solution is 
to use the 'screen' program.

More on that shell started from rc.local: this is really not the best way to 
handle this.  Instead, the following line should be added to /etc/inittab:

S0:12345:respawn:/sbin/getty ttyS0 9600 vt100

or, if agetty is installed on your system instead of getty:

S0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100

One of those lines, along with the already existing ones for the virtual
consoles, will add another console device to the existing ones, i.e. through
the serial port.  All console signals (CTRL-Z & al) will work without any
trouble, etc.


Nicolas

Re: virtual dumbness

[Brian Tew]

Thus spake David:
   >No. Do you have any protocol information for your VB2+? If so, perhaps we could
   >add a BRLTTY driver for it.

I don't really know what protocol information is even, but this vb2+ speaks plain
unadorned ascii < 128. There are no special
bits added to the ascii characters.
It was intended to plug in to any system and replace any dumb terminal.

serial i/o is via rs232 serial port; it has dce and dte both.

Here are the options on the serial parameters menu:
baud rate:  9600, 4800, 2400, 1200, 600, 300, 110, 75
lol, can you believe that?  75 baud.
data bits:  8, 7, 6 5
stop bits:  1, 1.5, 2
duplex:  full, half
parity:  odd, even, none, ignore
dc in:  yes, no
dc out:  yes, no
dtr:  high, low, hs
dsr:  yes, no
cts:  yes, no
rts:  high, low, hs


stty </dev/ttyS0 crtscts
worked perfectly, and im gitting perfect output 9600 baud.

You guys are a gold mine.

Re: virtual dumbness

[Dave Mielke]

[quoted lines by Brian Tew on March 23, 2002, at 08:26]

>this vb2+ speaks plain
>unadorned ascii < 128. There are no special
>bits added to the ascii characters.
>It was intended to plug in to any system and replace any dumb terminal.

Does it maintain an entire screen image, and give you controls to scroll around
that image? If so, what are the dimensions of the screen image, i.e. how many
lines and how many columns? How many characters are on the braille display? Is
it truly a dumb terminal, or does it support VT100 escape sequences?

-- 
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

virtual dumbness

[Brian Tew]

If I keep using my dumb ascii terminal hooked to com 1 for output,
do you think there is any way i can have virtual terminals?
It sure would be nice to zip around to different jobs with those f keys.
Sigh.

Re: virtual dumbness

[Henry Yen]

On Sat, Mar 23, 2002 at 03:56:35AM -0700, Brian Tew wrote:
> If I keep using my dumb ascii terminal hooked to com 1 for output,
> do you think there is any way i can have virtual terminals?
> It sure would be nice to zip around to different jobs with those f keys.
> Sigh.

you could try screen (man screen).  there are definitely commercial
apps that do that, and probably some free ones, too.
-- 
Henry Yen                                       Aegis Information Systems, Inc.
Senior Systems Programmer                       Hicksville, New York

Re: virtual dumbness

[Dave Mielke]

[quoted lines by Brian Tew on March 23, 2002, at 03:56]

>If I keep using my dumb ascii terminal hooked to com 1 for output,
>do you think there is any way i can have virtual terminals?

No. Do you have any protocol information for your VB2+? If so, perhaps we could
add a BRLTTY driver for it.

-- 
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

Re: virtual dumbness

[A. R. Vener]

Yes. I use the screen command to start up virtual terminals.
It is very easy to use.

Quick start:
1. login to your Linux machine, make sure your terminal is emulating
a vt100. 
2. enter screen to start up the screen manager
3. the screen manager sets the environment variable WINDOW to the 
screen number. I use this in my shell prompt under ksh like this:
  PS1="$WINDOW \$PATH> "

4. create a new terminal session with ctrl-A c
5. move from session to session using ctrl-A 0 to 9
6.see help screens with ctrl-a ?

Have fun.
Rudy

4. 


On Sat, Mar 23, 2002 at 03:56:35AM -0700, Brian Tew wrote:
> If I keep using my dumb ascii terminal hooked to com 1 for output,
> do you think there is any way i can have virtual terminals?
> It sure would be nice to zip around to different jobs with those f keys.
> Sigh.
> 
> 
> 
> _______________________________________________
> Blinux-list mailing list
> Blinux-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/blinux-list

Re: virtual dumbness

[Janina Sajka]

Why not? Or, to put it differently, what happens when you try it?

On Sat, 23 Mar 2002, Brian Tew wrote:

> If I keep using my dumb ascii terminal hooked to com 1 for output,
> do you think there is any way i can have virtual terminals?
> It sure would be nice to zip around to different jobs with those f keys.
> Sigh.
> 
> 
> 
> _______________________________________________
> Blinux-list mailing list
> Blinux-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/blinux-list
> 

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Chair, Accessibility SIG
Open Electronic Book Forum (OEBF)
http://www.openebook.org

Re: virtual dumbness

[Dave Mielke]

[quoted lines by Janina Sajka on March 23, 2002, at 07:34]

>Why not? Or, to put it differently, what happens when you try it?

He can't use Linux's virtual consoles the way he's sending output to his VB2+.
He's starting a shell from rc.local.

-- 
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

Re: virtual dumbness

[Janina Sajka]

On Sat, 23 Mar 2002, Dave Mielke wrote:

> [quoted lines by Janina Sajka on March 23, 2002, at 07:34]
> 
> >Why not? Or, to put it differently, what happens when you try it?
> 
> He can't use Linux's virtual consoles the way he's sending output to his VB2+.
> He's starting a shell from rc.local.
> 

Ah,my misunderstanding and my mistake. I'm very sorry.


> 

-- 
	
				Janina Sajka, Director
				Technology Research and Development
				Governmental Relations Group
				American Foundation for the Blind (AFB)

Email: janina@afb.net		Phone: (202) 408-8175

Chair, Accessibility SIG
Open Electronic Book Forum (OEBF)
http://www.openebook.org