Home > Archive > Tcl > May 2007 > telnet from spawned telnet process
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
telnet from spawned telnet process
|
|
| kbuzz3400@gmail.com 2007-05-25, 7:09 pm |
| 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
| |
| David Gravereaux 2007-05-25, 7:09 pm |
| kbuzz3400@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. Thisis 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
| |
| kbuzz3400@gmail.com 2007-05-28, 7:08 pm |
| On May 26, 1:16 pm, David Gravereaux <davyg...@pobox.com> wrote:
> kbuzz3...@gmail.com wrote:
>
> 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 w in this newsgroup. Please try the
> following steps:
> ...
>
> }
>
> 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
I appreciate you taking the time and effort to respond to my
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 w I will try to run the script on a unix box
and see what happens.
Thanks for your time,
Matt
| |
| David Gravereaux 2007-05-28, 7:08 pm |
| kbuzz3400@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 telnetprocess.
> 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 w 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'sside of
the fence.
--
Wormwood : Calvin, how about you?
Calvin : Hard to say ma'am. I think my cerebellum just fused.
| |
| kbuzz3400@gmail.com 2007-05-30, 7:10 pm |
| On May 28, 3:04 pm, David Gravereaux <davyg...@pobox.com> wrote:
> kbuzz3...@gmail.com wrote:
>
> Oh, so you're at the router's commandline and asking it to start a telnet process.
>
>
> 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
Yes, I was spawning the telnet, connecting to the router and then
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
|
|
|
|
|