Re: expect question

From: Brian Olmsted (NOSPAM_at_rogers.com)
Date: 04/07/04


Date: Wed, 07 Apr 2004 08:19:53 GMT


[[sorry for the longish post but this will probably be my last for now]]

Well I guess I will have to interview the heavy users a bit more to see what
their day to day usage is and what they typically do or use and state that
in order to put this temporary (yet possible long-term) fix in place I'll
have to ignore tab completion, and history with editing, etc..

I think they will have to realize that there will have to be some
concessions/limitations put in place in order to *easily* accomodate their
request to block this command without having to spend excessive time coading
for every possible editing feature they could do.

They actually won't be telnetting to UNIX systems but rather network devices
(ATM switches and the like) so I'm not actually simulating a shell, but
these devices typically have a very complex shell / command line interface
themselves

I can't see the typical user using featuers beyond regular typing,
backspacing and line editing using cursor keys so I probably don't have to
worry about control characters, etc that cause cursor repositioning or line
wipes (to end, to beginning, entire line, etc) becaue they probably don't
know about them (^U, ^W, etc). If I don't handle the control characters,
escape sequences explicitly it will add to my position counter and screw up
things as far as line editing because it will overrun what my buffer thinks
it has.

When I started to code this program on Friday and a bit of Saturday I didn't
know very much about what the switch could do so I just based it on what
typical UNIX shells like tcsh/bash can do and my previous experience with
Cisco equipment.

For example the Cisco equipment has tab completion just like tcsh/bash and
will complete the command structure (but there are hundreds of possible
commands so probably best to ignore tab).

Now, supposdely from talking to the main support contact for the effected
equipment it doesn't support tabs or history editing but there are other
devices from another vendor that user telnet to and this may peeve off those
users that like this functionality if they are used to using it. I guess
they can't have their cake and eat it too without me spending extensive time
coding this or having to look at doing it in perl with streams, etc and
ignoring the bad command that way, etc. I didn't want to make it too hard
to do / understand for the non-programmers in my group.

Anyway, the pressure is on for them to get something in place because this
command which would normally be a very commonly used command in previous
code releases causes the switch to roll over (crash) [service affecting to
the end customer] because the CLI interface in the switch doesn't handle it
properly and it will be quite some time before a fix that incoroprates all
of the desired changes is tested and approved by the vendor. I guess this
bug was introduced with this version of the code which was unknown at the
time, it took about a year to get up to this code level, the new code hasn't
been released to us yet, etc

However, it may be up to 1.5-2 years from now before the network is upgraded
again due to customer releases once the vendor gives us the fixed code so
this is why I'm worried that this script will be inplace for an extensive
period of time. After the code on the switches is upgraded I can then pull
out the script (if I'm still there!).

Also, to put another twist to it I may have to put in a special provision to
allow this bad command to be executed by support / engineering /
specialisits that know it is broken command as the command does work
provided it isn't mistyped { I guess the parser in the switch can't handle
it if it has the wrong switch name or something (don't know the details,
don't care ;) }. I guess this means putting in a hidden command such as
"~swch" where if they type the '~' (or something else) in front of the real
command I could look for it and then actually send "swch" but for the
general population this command would appear disabled.

I may take a quick look at those examples and see what they do and if I can
use them as a basis. I noticed in the code of one of the scripts that it
ignores the tabs like I did [says something about "got a tab' and does
nothing].

However, like any code it takes time to sit down and understand other
peoples code to see what it is doing (not a simple example) and I may have
to get this going quickly now that I've made mention of a working solution
(the relatively code segment that I emailed you to libes@nist.gov) .

Is there a reference table for the the ASCII/ANSI/Keyboard mappings, etc so
you know what to send for a cursor postion to the right, etc... I had to
hack at it before I got it to work and that wasn't easy. Also, I had to in
my script ^U (using <control-V><control-U>) in my script explicitly instead
of the hexidicmal/octal equivalent which is what I was looking for (this is
just an example, I have othe control characters). Is there a web site
about this as I'm not sure what to search for?

I'll look at these example terminal emulators in more detail and decide
where to go from here. At this point, I think my code segment that I
emailed you will probable suffice for now with maybe a few more cases to
handle the typical control characters (not escape sequences though) and the
hidden command. As I said they can't have their cake and eat it too... I
guess this will be a motivation for them to upgrade the switches as soon as
possible.

Anyways, thanks for your help Don. BTW, thanks for creating such a kick
ass language Don. As one of the quotes I saw to the effect "I don't
understand how UNIX survived without this for years". Anyways, It has
saved my bacon yet again. I'll be creating another expect script to talk
to another legacy switch under normal expect/send messages (not interacts)
in the next couple of days (since I'm the script go-to person now!)

And to anybody that doesn't have the book "Exploring Expect" (I may have an
older revision but still good). I highly recommend it in combination with
Internet sites and USENET groups. Worth every penny so far and I haven't
read it like a book but used it as a reference manual so far. To do what I
did in expect/interact would have taken way more code in perl or C I think
and harder to read, etc.

Gotta catch some ZZZZs as I can barely keep my eyes open....

Thanks again.
Cheers, Brian

"Don Libes" <libes@nist.gov> wrote in message
news:s6azn9pcbuz.fsf@peace.mel.nist.gov...
> Well, it depends on what you want to do. You say you want something
> "almost foolproof" in which case you're going to have to either
> knuckle down and do the hard work of emulating the terminal or
> emulating the shell. I'm merely suggesting the former is simpler.
> But a lot depends on your environment. For example, when I think of
> controlling shells, I wonder: Do users get to choose shells? Do they
> get to reprogram their editing keys? And so on. If you don't give
> your users any of those freedoms, yes, emulating the shell might not
> be as hard as I'm describing.
>
> As far as using interact vs expect, there're equivalent although
> interact is more easily aimed at continuing short interactions in both
> directions while expect is more easily aimed at one-time lengthy
> interactions in one direction.
>
> As for the examples, tkterm emulates a terminal (a la xterm) and you
> may not need the display that tkterm provides but it demonstrates how
> to parse the output of the spawned program to maintain a view of how
> it appears to the user.
>
> Don
>
>
>
>
>
> "Brian Olmsted" <NOSPAM@rogers.com> writes:
>
> > Hi Don,
> >
> > Can your provide me with some pointers to these terminal emulators
(rather
> > than shell emulators) examples that come with expect and how I would
> > use/call them? I'm using the sunfreeware package of expect and a
casual
> > perusal of the directory I found many ""term*" entries but not sure
which
> > one and how to call it, use it (see below)
> >
> > I'm confused as to when I should use interact and when I should use
> > expect.... The script I have working right now is one giant interact
> > with regular expressions for common/expected single keystrokes:
backspace,
> > delete, <control-D>, <control-A>, <control-E>, <control-U>, <control-C>,
tab
> > key (ignore with message), return key (check for bad command), left
arrow
> > (allow edit line), right arrow (allow edit line), up arrow (ignore with
> > message), down arrow (ignore with message), etc. I would have to add
> > control-[A-Z] not handled already in order for it to be almost fool
proof.
> >
> >
> > [olm8980@sparrow example]% pwd
> > /usr/local/doc/expect/example
> > [olm8980@sparrow example]% ls -l | grep term
> > -rwxr-xr-x 1 bin bin 29553 Mar 22 06:00 multixterm
> > -rw-r--r-- 1 bin bin 8945 Mar 22 06:00 multixterm.man
> > -rwxr-xr-- 1 bin bin 12288 Mar 22 06:00 term_expect
> > -rwxr-xr-- 1 bin bin 10120 Mar 22 06:00 tkterm
> > -rwxr-xr-- 1 bin bin 14822 Mar 22 06:00 virterm
> > [olm8980@sparrow example]%
> >
> >
> >
> > "Don Libes" <libes@nist.gov> wrote in message
> > news:s6a3c7ieeux.fsf@peace.mel.nist.gov...
> > > It occurs to me that a simpler approach to analyzing all user input
> > > and emulating the shell is instead to ignore the user input and simply
> > > watch the *output* from the spawned shell. This avoids having to
> > > handle history, for example, as a special thing.
> > >
> > > So how do you block commands? Simply watch for a \r or \n from the
> > > user. At that point, search the line for bad commands.
> > >
> > > Bottom line: building a terminal emulator is MUCH simpler than
> > > building a shell emulator. In fact, you could use the example one
> > > that comes with Expect.
> > >
> > > Don
> > >
> > >
> > >
> > > "Brian Olmsted" <NOSPAM@rogers.com> writes:
> > >
> > > > Hi Don,
> > > >
> > > > I used your suggestion and I think I've got something working by
> > buffering
> > > > the input that the user enters until they hit return. I then check
> > against
> > > > the buffer for the bad command that would be executed on the remote
> > device
> > > > and spit out a message saying executing such a command (anywhere on
the
> > > > line) is prohibitted.
> > > >
> > > > I've got it to handle backspace key and delete key entry by sending
the
> > > > delete key (\177 I believe) for either key and that seems to work
good
> > for
> > > > modifying my buffer and outputting to the screen. I was also able
to
> > > > handle using the left and right arrow keys to edit the command if
the
> > user
> > > > wishes to do so before hitting return.
> > > >
> > > > Now I have two questions at this point is.... (1) is there a way to
> > handle
> > > > the up and down arrow keys to get the command history and put it
into
> > the
> > > > buffer and then get the character position? (2) Also if the
remote
> > device
> > > > has tab completions is there a way of getting this into the buffer
and
> > then
> > > > trying to get the position of the cursor that reflects where the tab
> > > > completion would have expanded the line to?
> > > >
> > > >
> > > > Thanks
> > > > Brian
> > > >
> > > >
> > > > "Don Libes" <libes@nist.gov> wrote in message
> > > > news:s6ad66rag4v.fsf@peace.mel.nist.gov...
> > > > > You're correct. The code requires more work for backspaces. But
it's
> > > > > not hard. Just build a buffer and as backspaces arrive, remove
the
> > > > > last character from the buffer. More sophisticated editing
requires
> > > > > more work - which is the point of the last paragraph on the page
you
> > > > > cite.
> > > > >
> > > > > Don
> > > > >
> > > > >