|
|
 |
 |
 |
 |
TCL(Tool Command Language) Scripting
|
 |
 |
 |
 |
|
|
|
|
Expect scripting
Hello,
I have run into a problem where the [gets $filename line] cmd is not
giving me back the file name, but is giving back file#, where # is an
incrementing number.
Two questions:
Why does this happen?
What am I doing wrong?
Below is the code and the version information:
#########################################################
proc getcmdfile equipcmds {
# grabs the file path and name, sets the equip var from the var sent
to the subproc and sets the counter.
set cmdFile [open "/home/ke010596/$equipcmds\cmdfile.txt"]
send "\n$cmdFile\n"
return $cmdFile
}
##########################################################
OS: SunOS 5.4
tclversion: 8.4
expectversion:5.39.0
Knilges wrote: > Hello, > I have run into a problem where the [gets $filename line] cmd is not
> giving me back the file name, but is giving back file#, where # is an
> incrementing number.
neither matches your code later on, nor will it likely return the
result you are saying it returns (unless $filename is actually a file
handle, and the file contains a line like file#N).
> Two questions: > Why does this happen?
> set cmdFile [open "/home/ke010596/$equipcmds\cmdfile.txt"]
documented to do.
The above will open the file, and the return value will indeed be
something like "file#1". That's what it's supposed to do. This is a
handle you can then use to read from or write to the file, like so:
puts $cmdFile "hello, world"
-or-
gets $cmdFile line
-or-
read $cmdFile
Does that answer your question?
> Let's assume for a moment that the above code is just fiction since it
> neither matches your code later on, nor will it likely return the
> result you are saying it returns (unless $filename is actually a file
> handle, and the file contains a line like file#N).
> Does that answer your question?
I put only part of the code into the original post. I meant to put
the piece that is actually calling this subproc too. Yes, the first
question is answered, thank you. open is working as intended. I
figured my problem out. It was a mislabled var. Arggh!
Although I understand now that the open is only going to return a
system handle rather than what I thought it was going to do which was
assign a file name to the variable. Would that be why when I try to
pull several variable together in a string it doesn't know what I am
talking about?
example:
set file [open "$homedir/$myvar1-$myvar2.$mydatevar.txt"]
which doesn't seem to work when I try to do this.
Knilges wrote: >>Let's assume for a moment that the above code is just fiction since it >>neither matches your code later on, nor will it likely return the >>result you are saying it returns (unless $filename is actually a file >>handle, and the file contains a line like file#N). >>Does that answer your question?
> My apologies,
> I put only part of the code into the original post. I meant to put
> the piece that is actually calling this subproc too. Yes, the first
> question is answered, thank you. open is working as intended. I
> figured my problem out. It was a mislabled var. Arggh!
> Although I understand now that the open is only going to return a
> system handle rather than what I thought it was going to do which was
> assign a file name to the variable. Would that be why when I try to
> pull several variable together in a string it doesn't know what I am
> talking about?
> example:
> set file [open "$homedir/$myvar1-$myvar2.$mydatevar.txt"]
> which doesn't seem to work when I try to do this.
wrong. Show us your actual code and the actual result and we can help.
Here is the code I am trying to run. What I am trying to accomplish,
rather badly, is that if the command is entered with the arguements
li.exp l L i
,then the script would telnet to and login then transfer control back
to the user; however, if the following were to be entered
li.exp l L
,then the script would login and then send commands and capture them
to a file.
Right now if I put 'i' as the third arguement then it works properly,
but if I do not put the third arg then two things happen; first, the
program hangs until ^D is sent and then it telnets/logs-in, but the
script file is capturing the shell cmd line and the commands are never
sent to the telnet session. Originally, I thought it was just how I
had the file names that the commands were not being sent to the telnet
session, but now I think I have a different problem.
##########################################################
set mso [lindex $argv 0]
set equip [lindex $argv 1]
set login $env(LOGNAME)
set password [getpasswd "$equip"]
set mode [lindex $argv 2]
set mydate [exec date +%m%d%y]
set home $env(HOME)
if {$mode == "i"} {set mode "1"
} else { set mode "0" }
switch -- $equip \
L {
set outputfile $msoid\_$equipid-autodump.
$mydate.txt
set activeFile [open $home/ke010596/$equipid\cmdfile.txt"]
if { $mode == 0 } {
set counter "0"
exec script $outputfile
spawn telnet $msoTelnet$fourthOctet
expect "COMPL"
send "utl::login,user $login\r"
expect "PASSWORD"
send "$password\r"
expect "!"
while {[gets $activeFile line] != -1 } {
incr counter
send "$line\r"
expect "COMPL"
}
} elseif { $mode == 1 } {
spawn telnet $msoTelnet$fourthOctet
expect "COMPL"
send "utl::login,user $login\r"
expect "PASSWORD"
send "$password\r"
expect "!"
interact
etc.......
#####################################################
In article <1179617918.007600.59@w5g2000hsg.googlegroups.com>,
Knilges <knil @hotmail.com> wrote: >Here is the code I am trying to run. What I am trying to accomplish, >rather badly, is that if the command is entered with the arguements >li.exp l L i
>,then the script would telnet to and login then transfer control back
>to the user; however, if the following were to be entered
>li.exp l L
>,then the script would login and then send commands and capture them
>to a file.
>Right now if I put 'i' as the third arguement then it works properly,
>but if I do not put the third arg then two things happen; first, the
>program hangs until ^D is sent and then it telnets/logs-in, but the
>script file is capturing the shell cmd line and the commands are never
>sent to the telnet session. Originally, I thought it was just how I
>had the file names that the commands were not being sent to the telnet
>session, but now I think I have a different problem.
>##########################################################
> set mso [lindex $argv 0]
> set equip [lindex $argv 1]
> set login $env(LOGNAME)
> set password [getpasswd "$equip"]
> set mode [lindex $argv 2]
> set mydate [exec date +%m%d%y]
> set home $env(HOME)
>if {$mode == "i"} {set mode "1"
> } else { set mode "0" }
>switch -- $equip \
> L {
> set outputfile $msoid\_$equipid-autodump.
>$mydate.txt
> set activeFile [open $home/ke010596/$equipid\cmdfile.txt"]
> if { $mode == 0 } {
> set counter "0"
> exec script $outputfile
> spawn telnet $msoTelnet$fourthOctet
> expect "COMPL"
> send "utl::login,user $login\r"
> expect "PASSWORD"
> send "$password\r"
> expect "!"
> while {[gets $activeFile line] != -1 } {
> incr counter
> send "$line\r"
> expect "COMPL"
> }
> } elseif { $mode == 1 } {
> spawn telnet $msoTelnet$fourthOctet
> expect "COMPL"
> send "utl::login,user $login\r"
> expect "PASSWORD"
> send "$password\r"
> expect "!"
> interact
>etc.......
>#####################################################
I say that to encourage, not discourage. Your project
sounds like an interesting one, and Expect is certain
to be a part of any well-formed solution.
However, there's an excess of noise in your presentation;
this makes it difficult for us to help effectively. Even
leaving aside such stylistic matters as the $mode revalu-
ation, unnecessary reliance on [exec], and superfluous
\-escapes, a line like
set activeFile [open $home/ke010596/$equipid\cmdfile.txt"]
gives me deep doubt about how accurately you've rendered
the situation (what's with the unbalanced ", and do you
really intend what is more conventionally written
${equipid}cmdfile.txt
?).
As written, this program *can't* "hang"; it *must*
send $line\r
if perhaps with timeouts intervening. Are you *sure*
COMPL is the exact prompt from the remote processor?
I strongly recommend you read <URL: http://wiki.tcl.tk/3173 >.
> You're working too hard.
hanging out on the golf course enjoying sunny days... that can't be
good for me!
> However, there's an excess of noise in your presentation;
> this makes it difficult for us to help effectively.
> Even
> leaving aside such stylistic matters as the $mode revalu-
> ation, unnecessary reliance on [exec]
I couldn't think of how to capture text from a telnet session so again
I reverted to what I am familiar with which is script and used exec
although I though spawn would do the same thing. What is the
difference there? My thoughts were that exec is using the shell and
spawn is basically doing the same. Is that misguided?
, and superfluous
> \-escapes, a line like
> set activeFile [open $home/ke010596/$equipid\cmdfile.txt"]
> gives me deep doubt about how accurately you've rendered
> the situation (what's with the unbalanced ", and do you
> really intend what is more conventionally written
> ${equipid}cmdfile.txt
> ?).
I did, but when I tried it I did it incorrectly because originally, I
had $equipidcmdfile.txt was getting that the var $equipidcmdfile was
not found. But I thought to use braces, {?equipid}, to segregate the
var but that didn't work so I reverted to '\' but now that you pointed
out my mistake I corrected that. The unbalanced " was typo in my
email not in the code.
> As written, this program *can't* "hang"; it *must*
> send $line\r
Okay but as written is $line garanteed to be filled? Or is the
problem that $line is not getting anything? I can say the $
{equipid}cmdfile.txt does have a line that is a valid command to the
system it is suppose to be sent to," utl::qry.who! ". The ! is the
system's \n character.
> if perhaps with timeouts intervening.
This made me look at my code again and after the password is
successful I had it waiting for a ! which was never going to appear
without a \r being sent instead it should have been waiting for COMPL.
> Are you *sure*
> COMPL is the exact prompt from the remote processor?
Yes. If the command were to be entered to the telnet session to this
piece of equipment the response for every command is COMPL.
Recommendation appreciated and will be taken. Thank you.
But I guess the short of it is, not that I am discouraged, my code is
a mess and heaven help me!
Knilges wrote:
> I couldn't think of how to capture text from a telnet session so again
> I reverted to what I am familiar with which is script and used exec
> although I though spawn would do the same thing. What is the
> difference there?
> My thoughts were that exec is using the shell and
> spawn is basically doing the same. Is that misguided?
Shoot your guidedog! ;-)
NEITHER uses the shell.
exec has a shell-similar piping and redirection syntax.
but it ends there.
spawn hangs your process onto the tty side of a pty.
i.e. your spawned program will feel right at home just
like in the interactive environment it was written for.
uwe
In article <1179633080.403856.193@w5g2000hsg.googlegroups.com>,
Knilges <knil @hotmail.com> wrote:
.
.
>> As written, this program *can't* "hang"; it *must* >> send $line\r >Okay but as written is $line garanteed to be filled? Or is the
>problem that $line is not getting anything? I can say the $
>{equipid}cmdfile.txt does have a line that is a valid command to the
>system it is suppose to be sent to," utl::qry.who! ". The ! is the
>system's \n character.
>> if perhaps with timeouts intervening.
>This made me look at my code again and after the password is
>successful I had it waiting for a ! which was never going to appear
>without a \r being sent instead it should have been waiting for COMPL.
.
.
Your construction of
$home/ke010596/$equipid\cmdfile.txt
was clever.
Yes, as your program reached me, $line is guaranteed to have
meaningful content.
My suggestion--correct the COMPL prompting, simplify your
example a bit, and post it, along with the symptoms you re-
ceive, again. OR work through the debugging techniques I
described earlier, and then tell us if any mysteries remain.
|
|
|
|
|
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc