Discussion:
[rancid] clogin bug setting prompt
Casey T. Deccio
2008-02-27 18:36:14 UTC
Permalink
Apologies if this is known already. I am running RANCID 2.3.1 with
expect 5.42.1. In clogin there is a bug in setting the prompt
appropriately for switches using the "xyz> (enable)" prompt (or any
other prompts including characters with special regex meaning--besides
brackets). The parentheses from the $expect_out(buffer) are not escaped
when the prompt variable is updated, so when "expect -re $prompt {}" is
called, the prompt matches "xyz> enable" but not "xyz> (enable)". I've
attached a patch to clogin (it includes other characters too, just in
case they may need to be escaped also).

Regards,
Casey
Lance Vermilion
2008-02-27 19:30:53 UTC
Permalink
Casey,

Did you notice this issue on any alpha versions?

-Lance
Post by Casey T. Deccio
Apologies if this is known already. I am running RANCID 2.3.1 with
expect 5.42.1. In clogin there is a bug in setting the prompt
appropriately for switches using the "xyz> (enable)" prompt (or any
other prompts including characters with special regex meaning--besides
brackets). The parentheses from the $expect_out(buffer) are not escaped
when the prompt variable is updated, so when "expect -re $prompt {}" is
called, the prompt matches "xyz> enable" but not "xyz> (enable)". I've
attached a patch to clogin (it includes other characters too, just in
case they may need to be escaped also).
Regards,
Casey
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss
Casey T. Deccio
2008-02-27 22:21:01 UTC
Permalink
Post by Lance Vermilion
Did you notice this issue on any alpha versions?
Lance,

I haven't had a chance yet to test the alpha version, but upon browsing
through the code, I saw the same problem with the setting of prompt.
I'll confirm that when I can.

Regards,
Casey
Post by Lance Vermilion
Post by Casey T. Deccio
Apologies if this is known already. I am running RANCID 2.3.1 with
expect 5.42.1. In clogin there is a bug in setting the prompt
appropriately for switches using the "xyz> (enable)" prompt (or any
other prompts including characters with special regex meaning--besides
brackets). The parentheses from the $expect_out(buffer) are not escaped
when the prompt variable is updated, so when "expect -re $prompt {}" is
called, the prompt matches "xyz> enable" but not "xyz> (enable)". I've
attached a patch to clogin (it includes other characters too, just in
case they may need to be escaped also).
Regards,
Casey
Casey T. Deccio
2008-02-28 00:52:15 UTC
Permalink
Post by Lance Vermilion
Did you notice this issue on any alpha versions?
I confirmed this problem on 2.3.2a7.

Casey
Post by Lance Vermilion
Post by Casey T. Deccio
Apologies if this is known already. I am running RANCID 2.3.1 with
expect 5.42.1. In clogin there is a bug in setting the prompt
appropriately for switches using the "xyz> (enable)" prompt (or any
other prompts including characters with special regex meaning--besides
brackets). The parentheses from the $expect_out(buffer) are not escaped
when the prompt variable is updated, so when "expect -re $prompt {}" is
called, the prompt matches "xyz> enable" but not "xyz> (enable)". I've
attached a patch to clogin (it includes other characters too, just in
case they may need to be escaped also).
Regards,
Casey
john heasley
2008-02-27 20:35:31 UTC
Permalink
Post by Casey T. Deccio
Apologies if this is known already. I am running RANCID 2.3.1 with
expect 5.42.1. In clogin there is a bug in setting the prompt
appropriately for switches using the "xyz> (enable)" prompt (or any
other prompts including characters with special regex meaning--besides
brackets). The parentheses from the $expect_out(buffer) are not escaped
when the prompt variable is updated, so when "expect -re $prompt {}" is
called, the prompt matches "xyz> enable" but not "xyz> (enable)". I've
attached a patch to clogin (it includes other characters too, just in
case they may need to be escaped also).
Not escaping the () grouping atoms for Catalyst prompts is definitely a bug,
thanks.

I suppose not escaping the . atom is also a bug; is there a reason that you
only applied this fix to Catalyst prompts?

As for the +?{} atoms, these simply seem inappropriate for prompts. Just
as '(enable)' rather offensive. I feel inclined to suggest that the
configuration should be fixed rather than make this change. Is that short
sighted?
Post by Casey T. Deccio
--- clogin 2008-02-27 10:26:09.000000000 -0800
+++ clogin.new 2008-02-27 10:26:47.000000000 -0800
@@ -751,7 +751,7 @@
}
-re "^.+> \\\(enable\\\)" {
set junk $expect_out(0,string);
- regsub -all "\[\]\[]" $junk {\\&} prompt;
+ regsub -all "\[\]\[\(\)+.?{}]" $junk {\\&} prompt;
}
}
_______________________________________________
Rancid-discuss mailing list
http://www.shrubbery.net/mailman/listinfo.cgi/rancid-discuss
Casey T. Deccio
2008-02-27 22:13:29 UTC
Permalink
Post by john heasley
Not escaping the () grouping atoms for Catalyst prompts is definitely a bug,
thanks.
I suppose not escaping the . atom is also a bug; is there a reason that you
only applied this fix to Catalyst prompts?
Only because I hadn't used and found it while working on a Catalyst
platform. The change would be easy to implement on the other *login
scripts, but I wouldn't have any way to test it. But I did add this to
the other case in clogin (new patch).
Post by john heasley
As for the +?{} atoms, these simply seem inappropriate for prompts. Just
as '(enable)' rather offensive. I feel inclined to suggest that the
configuration should be fixed rather than make this change. Is that short
sighted?
I don't know that it is reasonable to expect that an administrator will
use the +?{} atoms in the prompt. However, it certainly is *allowable*
to use .+{}[]() (not "?") in the prompt (on Catalyst prompts anyway). I
favor more general cases (i.e., escaping any atoms), but that's just my
opinion FWIW.

Regards,
Casey
Casey T. Deccio
2008-02-28 00:26:01 UTC
Permalink
Post by Casey T. Deccio
Apologies if this is known already. I am running RANCID 2.3.1 with
expect 5.42.1. In clogin there is a bug in setting the prompt
appropriately for switches using the "xyz> (enable)" prompt (or any
other prompts including characters with special regex meaning--besides
brackets). The parentheses from the $expect_out(buffer) are not escaped
when the prompt variable is updated, so when "expect -re $prompt {}" is
called, the prompt matches "xyz> enable" but not "xyz> (enable)". I've
attached a patch to clogin (it includes other characters too, just in
case they may need to be escaped also).
I think the patch I created is the wrong fix in the wrong place. I'm
guessing the substitution I refer to in the patch is meant for escaping
only the square brackets, so TCL does not interpret them as a command.
It was not intended to escape regex atoms.

The appropriate escaping of regex atoms is performed in the first ~25
lines of the run_commands proc. The problem is that this code isn't run
if the -s switch is used. Maybe it would be most beneficial to define a
proc that returned a reprompt, which was then called after getting the
"full prompt"? Then the resulting $reprompt could be used by both the
run_commands proc and subsequent commands for the file.

Casey
Loading...