|
|
 |
 |
 |
 |
TCL(Tool Command Language) Scripting
|
 |
 |
 |
 |
|
|
|
|
telnet from spawned telnet process
I have an expect script that spawns a telnet process, logs into a
router and then tries to use the router's telnet to connect to a unix
box. Manually, this works fine. However, when I put the same logic
into the expect script, it does not work correctly.
I log into the router fine but then when I send the telnet command
from the router, nothing happens. I would expect to be prompted for
the unix box user id/passwd but instead the router prompt comes right
back with no prompt, no error messages nothing.
The send command is:
send "telnet 106.40.6.52\r"
My scripts are running on windows xp with active state tcl 8.4.14
thanks,
Matt
kbuzz3 @gmail.com wrote: > I have an expect script that spawns a telnet process, logs into a > router and then tries to use the router's telnet to connect to a unix > box. Manually, this works fine. However, when I put the same logic > into the expect script, it does not work correctly. > I log into the router fine but then when I send the telnet command > from the router, nothing happens. I would expect to be prompted for > the unix box user id/passwd but instead the router prompt comes right > back with no prompt, no error messages nothing. > The send command is:
> send "telnet 106.40.6.52\r"
> My scripts are running on windows xp with active state tcl 8.4.14
> thanks,
> Matt
rather frequently asked question.
1) dbghelp.dll on XPsp2 is rather broken.
2) AMD processors have a security attribute that needs disabling.
Use [exp_send] rather than [send] due to name collision issues.
--
YAAH! DEATH TO OATMEAL!
-- Calvin
On May 25, 12:51 pm, David Gravereaux <davyg@pobox.com> wrote:
> kbuzz3 @gmail.com wrote: > > I have an expect script that spawns a telnet process, logs into a > > router and then tries to use the router's telnet to connect to a unix > > box. Manually, this works fine. However, when I put the same logic > > into the expect script, it does not work correctly. > > I log into the router fine but then when I send the telnet command > > from the router, nothing happens. I would expect to be prompted for > > the unix box user id/passwd but instead the router prompt comes right > > back with no prompt, no error messages nothing. > > The send command is:
> > send "telnet 106.40.6.52\r"
> > My scripts are running on windows xp with active state tcl 8.4.14
> > thanks,
> > Matt
> Please search the ActiveState expect mailing list for the solution. This is a
> rather frequently asked question.
> 1) dbghelp.dll on XPsp2 is rather broken.
> 2) AMD processors have a security attribute that needs disabling.
> Use [exp_send] rather than [send] due to name collision issues.
> --
> YAAH! DEATH TO OATMEAL!
> -- Calvin
> signature.asc
> 1KDownload
Thanks for the response. Sorry to have repeated an often asked
question. I had looked online for help and did not see anything
(after your response I did go and look and find your posting).
I tried the 3 suggestions and it did not work.
1. the exp_send did not make a difference (I actually had tried that
before).
2. I had made the changes to the boot.ini file a while ago because the
spawn command wouldn't work with the way it was.
3. I download the windows debugger that was linked to your message. I
also went through and checked the revisions of the gbphelp.dll and
there several in different directories. The rev on all of them but
one were fine (one with Trillian). I took it off and still see the
problem.
I don't suppose you have any other idea?
Thank you for your help,
Matt
On May 25, 10:51 am, kbuzz3@gmail.com wrote:
> I have an expect script that spawns a telnet process, logs into a > router and then tries to use the router's telnet to connect to a unix > box. Manually, this works fine. However, when I put the same logic > into the expect script, it does not work correctly. > I log into the router fine but then when I send the telnet command > from the router, nothing happens. I would expect to be prompted for > the unix box user id/passwd but instead the router prompt comes right > back with no prompt, no error messages nothing. > The send command is:
> send "telnet 106.40.6.52\r"
> My scripts are running on windows xp with active state tcl 8.4.14
> thanks,
> Matt
and
see what results. Then compare this against your script. Also check
the
environment (TERM=?) and the stty status at each step ( raw or cooked
echo or noecho) .
Telnet is not a straight socket connection there is a negotiation step
that occurs
first and perhaps you are failing that. For instance you may need to
turn on echoing to
see the prompts for the second telnet
session. Make sure you are only expecting things that will not
change over time and that the unix machine
is connectable when you run your script.
Carl
Carl
On May 25, 2:03 pm, Bezoar <cwjo@gmail.com> wrote:
> On May 25, 10:51 am, kbuzz3 @gmail.com wrote: > > I have an expect script that spawns a telnet process, logs into a
> > router and then tries to use the router's telnet to connect to a unix
> > box. Manually, this works fine. However, when I put the same logic
> > into the expect script, it does not work correctly.
> > I log into the router fine but then when I send the telnet command
> > from the router, nothing happens. I would expect to be prompted for
> > the unix box user id/passwd but instead the router prompt comes right
> > back with no prompt, no error messages nothing.
> > The send command is:
> > send "telnet 106.40.6.52\r"
> > My scripts are running on windows xp with active state tcl 8.4.14
> > thanks,
> > Matt
> When you do this activity manually do it inside an autoexpect session
> and
> see what results. Then compare this against your script. Also check
> the
> environment (TERM=?) and the stty status at each step ( raw or cooked
> echo or noecho) .
> Telnet is not a straight socket connection there is a negotiation step
> that occurs
> first and perhaps you are failing that. For instance you may need to
> turn on echoing to
> see the prompts for the second telnet
> session. Make sure you are only expecting things that will not
> change over time and that the unix machine
> is connectable when you run your script.
> Carl
> Carl
OK. I went through and check the stty status. It was cooked and
echo. I cycled through the various combinations (both from the
interpreter and via script) and none of them worked. ie:
expect3.17> stty noecho
-raw echo
expect3.18> send "telnet 106.40.6.52 \r"
expect3.19> expect {"login.*" {send_user "hello\r"}}
telnet 106.40.6.52
# expect3.20>
expect3.20>
I checked the TERM. When I run from cygwin window the TERM is
cygwin. When I run from a dos prompt, there is not term. Either way
returns the same thing.
thank you for your help,
Matt
kbuzz3 @gmail.com wrote: > David, > Thanks for the response. Sorry to have repeated an often asked > question. I had looked online for help and did not see anything > (after your response I did go and look and find your posting).
subst {
Hello ${name},
Your question about Expect for Windows (E4W) can be answered with this form letter
as this question comes up about once a week in this newsgroup. Please try the
following steps:
...
}
> I don't suppose you have any other idea?
Does the process that you spawn, then create new processes that you want Expect to
trap as well? I'm not sure if that aspect works right. I know that if you spawn
cmd.exe then ask it to start a process, expect won't grab the output from the new
process. I'm not sure why that doesn't work, but I'm sure it is fixable.
Who's going to fix it is the big question. Even though the source for it is open,
no one seems to assist with its development.
The big problem with E4W is its lack of a X-platform test suite.. It only works
on Unix, or most are skipped on win due to system differences which ever your
perspective. For example, the 'od' command does not exist on windows. Nor are
any windows specific tests contained in it, such as the shell problem. Thinking
to the future toward a working [interact] command, the test suite would need to be
rather large to make sure all Console APIs are properly "copied" to the user
console and would require lots of C-based exercises.
It wouldn't be so bad if the technique of trapping console output on windows
wasn't so damn complicated. The feature to do it does not exist in the OS the way
it does on Unix. IOW, it forces what is not expressed as a stream into one. I
wouldn't call what E4W does a hack job, but it comes close. I was even tempted to
try a technique called 'Detours', which is similar in concept but uses import
table memory rewriting rather than setting breakpoints with the system debugger
for redirection. 'Detours' would probably be more efficient, but I didn't think
Microsoft's license agreement was friendly enough.
http://research.microsoft.com/sn/detours/
PS. I give myself to permission to insult E4W, should it be warranted for the
conversation, because I wrote it. IOW, I adapted Gordon Chaffee's old 1996 work
into the modern code base a couple years ago. I had to make very deep and drastic
changes to allow a generic/platform split. I pulled out enough hair to make a wig.
PPS. don't get me started on Tcl's channel API ;)
--
Calvin : I think we have got enough information now, don't you?
Hobbes : All we have is one "fact" that you made up.
Calvin : That's plenty. By the time we add an introduction, a few
illustrations and a conclusion, it'll look like a graduate thesis.
David Gravereaux wrote:
> For example, the 'od' command does not exist on windows.
It does. It's just not normally installed as it's a third-party piece of
code. But I do have a copy on my system, from the UnxUtils set. :-)
This is why tests should not normally be written to rely on platforms to
provide constraints but instead describe the precise features required.
Sometimes that's difficult to do I know but it's still what's Right. But
this case illustrates why tests should be done that way all the same.
Donal.
On May 26, 1:16 pm, David Gravereaux <davyg@pobox.com> wrote:
> kbuzz3 @gmail.com wrote: > > David, > > Thanks for the response. Sorry to have repeated an often asked > > question. I had looked online for help and did not see anything > > (after your response I did go and look and find your posting). > I should make a form letter with inserts :)
> subst {
> Hello ${name},
> Your question about Expect for Windows (E4W) can be answered with this form letter
> as this question comes up about once a week in this newsgroup. Please try the
> following steps:
> ...
> }
> > I don't suppose you have any other idea?
> Does the process that you spawn, then create new processes that you want Expect to
> trap as well? I'm not sure if that aspect works right. I know that if you spawn
> cmd.exe then ask it to start a process, expect won't grab the output from the new
> process. I'm not sure why that doesn't work, but I'm sure it is fixable.
> Who's going to fix it is the big question. Even though the source for it is open,
> no one seems to assist with its development.
> The big problem with E4W is its lack of a X-platform test suite.. It only works
> on Unix, or most are skipped on win due to system differences which ever your
> perspective. For example, the 'od' command does not exist on windows. Nor are
> any windows specific tests contained in it, such as the shell problem. Thinking
> to the future toward a working [interact] command, the test suite would need to be
> rather large to make sure all Console APIs are properly "copied" to the user
> console and would require lots of C-based exercises.
> It wouldn't be so bad if the technique of trapping console output on windows
> wasn't so damn complicated. The feature to do it does not exist in the OS the way
> it does on Unix. IOW, it forces what is not expressed as a stream into one. I
> wouldn't call what E4W does a hack job, but it comes close. I was even tempted to
> try a technique called 'Detours', which is similar in concept but uses import
> table memory rewriting rather than setting breakpoints with the system debugger
> for redirection. 'Detours' would probably be more efficient, but I didn't think
> Microsoft's license agreement was friendly enough.
> http://research.microsoft.com/sn/detours/
> PS. I give myself to permission to insult E4W, should it be warranted for the
> conversation, because I wrote it. IOW, I adapted Gordon Chaffee's old 1996 work
> into the modern code base a couple years ago. I had to make very deep and drastic
> changes to allow a generic/platform split. I pulled out enough hair to make a wig.
> PPS. don't get me started on Tcl's channel API ;)
> --
> Calvin : I think we have got enough information now, don't you?
> Hobbes : All we have is one "fact" that you made up.
> Calvin : That's plenty. By the time we add an introduction, a few
> illustrations and a conclusion, it'll look like a graduate thesis.
> signature.asc
> 1KDownload
question, especially considering that this question does not break any
new or interesting ground :)
I don't understand what the underlying processes from a spawn
command are or what exactly that means from TCL/Expect's perspective.
My thinking woud have been that the telnet from the router was not
spawning a new process but was merely a command sent to the router
like any other command like showing subscribers or the router time.
Got to say not exactly thrilled with this turn of events since what
for what I am trying to accomplish at the moment is a script to
demonstrate the ability of the router to do a telnet. I guess out of
curiosity sake, next week I will try to run the script on a unix box
and see what happens.
Thanks for your time,
Matt
kbuzz3 @gmail.com wrote: > My thinking woud have been that the telnet from the router was not > spawning a new process but was merely a command sent to the router > like any other command like showing subscribers or the router time.
> Got to say not exactly thrilled with this turn of events since what
> for what I am trying to accomplish at the moment is a script to
> demonstrate the ability of the router to do a telnet. I guess out of
> curiosity sake, next week I will try to run the script on a unix box
> and see what happens.
Still have no clue why it wouldn't work for you. Aside from a $TERM thing as seen
to the router's telnet process, I can't think of anything on the window's side of
the fence.
--
Wormwood : Calvin, how about you?
Calvin : Hard to say ma'am. I think my cerebellum just fused.
On May 28, 3:04 pm, David Gravereaux <davyg@pobox.com> wrote:
> kbuzz3 @gmail.com wrote: > > My thinking woud have been that the telnet from the router was not > > spawning a new process but was merely a command sent to the router > > like any other command like showing subscribers or the router time. > Oh, so you're at the router's commandline and asking it to start a telnet process.
> > Got to say not exactly thrilled with this turn of events since what
> > for what I am trying to accomplish at the moment is a script to
> > demonstrate the ability of the router to do a telnet. I guess out of
> > curiosity sake, next week I will try to run the script on a unix box
> > and see what happens.
> Still have no clue why it wouldn't work for you. Aside from a $TERM thing as seen
> to the router's telnet process, I can't think of anything on the window's side of
> the fence.
> --
> Wormwood : Calvin, how about you?
> Calvin : Hard to say ma'am. I think my cerebellum just fused.
> signature.asc
> 1KDownload
using the router's commandline to try and connect to a unix box.
However, I do seem to have it working. A long story short, I
suspect that it has to do with the WILL/WONT/DO/DONT stuff but I am
not 100% positive. However, when the initial spawn is done, I
switched from using the cygwin telnet to the MS telnet and it appears
to work fine. Of course, I switched from the MS telnet in the first
place because it appeared to cause my scripts to freeze. sigh.
thanks again for all the help.
Matt
|
|
|
|
|
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc