Discussion:
[rancid] '>' in default prompt causes problems for zrancid
Tore Anderson
2014-04-16 08:52:07 UTC
Permalink
After an upgrade from RANCID 2.3.2, zrancid is creating bogus diffs.
They always involve the character «e» appearing/disappearing at the
beginning of lines, like so:

-log file /var/log/quagga/zebra.log
+elog file /var/log/quagga/zebra.log

Or at the end of lines, like so:

- ipv6 nd suppress-ra
+ ipv6 nd suppress-rae

I've traced this to a change in the default prompt in clogin.in that
happened in RANCID 2.3.6. Fast forwarding to RANCID 3.0, the relevant
code is as follows (lines 766-770 of clogin.in):

# Default prompt.
set prompt [join [find prompt $router] ""]
if { [llength $prompt] == 0 } {
set prompt "(>|#| \\(enable\\))"
}

In RANCID 2.3.5 and earlier, $prompt was set to "(#| \\(enable\\))" by
default, and that worked perfectly for me.

I haven't yet been able to fully understand why the ">" match is causing
problems, but I did notice that it causes $prompt_match to always be set
to ">" at lines 576-579 of clogin.in:

-re "$prompt" {
set prompt_match $expect_out(0,string);
break;
}

However, the routers in question don't use ">" in their prompt (they use
"#"), so I don't think this can be right.

Attempting to escape the ">" (using "\>" or "\\>") makes no difference.
Removing it or replacing it with any other character (including "<")
does help, though, and in this case $prompt_match gets set to "#" as
expected, and the spurious «e» characters stop appearing.

The platform is Ubuntu 12.04.4 with expect 5.45.

Tore
Tore Anderson
2014-04-23 07:37:55 UTC
Permalink
* Tore Anderson
Post by Tore Anderson
I haven't yet been able to fully understand why the ">" match is causing
problems, but I did notice that it causes $prompt_match to always be set
-re "$prompt" {
set prompt_match $expect_out(0,string);
break;
}
However, the routers in question don't use ">" in their prompt (they use
"#"), so I don't think this can be right.
I've finally figured out what's going on here. It appears that when
$TERM is vt100 (and a bunch of others), vtysh prints out some
(invisible) terminal control codes before the actual prompt. These
include the '>' character, so that's why the prompt matching fails.

This is how the prompt looks when run through "cat -A", FWIW:

^[[?1h^[=^M^M^[[K^[[?1l^[>routername# $

Changing $TERM to something else solves the problem and these garbage
characters disappear. On my Ubuntu 12.04, the following values of $TERM
all seems to work OK:

ansi
cons25
cons25-debian
cygwin
Eterm
Eterm-color
hurd
linux
mach
mach-bold
mach-color
pcansi
sun
vt220
vt52
wsvt25
wsvt25m

Not sure which one of these is the most portable, but in any case, I
suggest changing the hard-coding of $TERM to "vt100" in zrancid to
either of these (or removing it so that it can be set from rancid.conf
instead). Suggested one-line patch attached.

Tore

Loading...