Prev: sending email with smtp package
Next: Xming X11 server and fullscreen mode
From: Dave on 11 Jun 2010 09:21
On Jun 9, 9:04 am, Dave <hende...(a)gmail.com> wrote:
> On Jun 8, 4:32 pm, Uwe Klein <uwe_klein_habertw...(a)t-online.de> wrote:
>
>
>
> > you can compact/factorise that quite a bit:
>
> > switch -- $sucom \
> >           sudo {
> >                 ...........
> >                 set spawn [ list spawn  ....
> >         } su    {
> >                 ...........
> >                 set spawn [list spawn  ....
> >         } default {
> >                 error "unknown sucom param"
> >         }
>
> > if {[catch $spawn cerr]} {
> >                 error "spawning $spawn doesnt work"}
>
> > expect \
> >           -re " password for |assword: " {
> >                 send -i $PID "$password\r"
> >                 # continue looping in this 'expect' block until the 'prompt' is reached
> >                 exp_continue
> >         } -re "$prompt" {
> >                 exit 0
> >         } timeout {
> >            send_user "Timeout waiting for password."
> >            exit 1
> >         } * {
> >            send_user "There was an error.\n"
> >            exit 1
> >         } eof {
> >                 exit 0
> >         }
>
> > something like this?
>
> > observe $spawn_id has nothing to do with a process id!
>
> I'm going to try adjusting the code to more closely follow whats been
> provided above.  In the mean time, can the parts like "set spawn [list
> spawn  ...." be substituted for "set spawn { spawn -noecho sudo
> $syntax } curr_result".  I'm not an Expect programmer, so I'm not sure
> what the ....'s can represent in regards to porting the code to the
> above example.  Also, I see that the catch has been implemented
> differently than in the original code, however, it doesn't appear that
> any error messages from the syntax to be executed will be returned,
> just hard coded "spawning $spawn doesnt work".  I need to be able to
> return any error/success messages from the executed syntax to the
> user.  Thanks, everyone, for the help so far!
>
> Dave


bump for help
From: Uwe Klein on 11 Jun 2010 10:22
Dave wrote:
>>I'm going to try adjusting the code to more closely follow whats been
>>provided above. In the mean time, can the parts like "set spawn [list
>>spawn ...." be substituted for "set spawn { spawn -noecho sudo
>>$syntax } curr_result".
>
> bump for help

We ( me, King of TCL,
actually the lack of replies would indicate the c.l.t community)
would think that as things stand now reading up a bit about expect
commands [spawn] [expect] [wait] ...
and tcl commands in general like [catch] would bring you forward
in a more productive way.

Notice: catch runs the script given as first agument, catches all errors
and sets the optional second argument to either the value produced by
that script or the errormessage in case of error, while the return value
from [catch] is the error number given in tcl.h ( zero for success )

<tcl.h>
* TCL_OK Command completed normally; the interpreter's
* result contains the command's result.
* TCL_ERROR The command couldn't be completed successfully;
* the interpreter's result describes what went wrong.
* TCL_RETURN The command requests that the current procedure
* return; the interpreter's result contains the
* procedure's return value.
* TCL_BREAK The command requests that the innermost loop
* be exited; the interpreter's result is meaningless.
* TCL_CONTINUE Go on to the next iteration of the current loop;
* the interpreter's result is meaningless.
*/

#define TCL_OK 0
#define TCL_ERROR 1
#define TCL_RETURN 2
#define TCL_BREAK 3
#define TCL_CONTINUE 4


uwe
From: Larry W. Virden on 11 Jun 2010 10:58
On Jun 9, 9:04 am, Dave <hende...(a)gmail.com> wrote:

> In the mean time, can the parts like "set spawn [list
> spawn  ...." be substituted for "set spawn { spawn -noecho sudo
> $syntax } curr_result".  

In tcl, when someone writes:

set a [b c d]

this means "Assign the results of executing the command b (passing in
arguments c and d) to the variable a."
So the sample you mention is saying:
Don't execute a spawn command and assign its results to $spawn.
Instead, set $spawn to a string that can be executed to perform a
spawn operating (that's the purpose of sticking that list in front of
the command).


>I'm not an Expect programmer, so I'm not sure
> what the ....'s can represent in regards to porting the code to the
> above example.  

The ... represents whatever you need to happen at that point.


>Also, I see that the catch has been implemented
> differently than in the original code, however, it doesn't appear that
> any error messages from the syntax to be executed will be returned,
> just hard coded "spawning $spawn doesnt work".  I need to be able to
> return any error/success messages from the executed syntax to the
> user.  

If you need to know the specific error, then change the example to
say:

if {[catch $spawn cerr]} {
error "spawning $spawn doesnt work - $cerr"
}

and the error that was caught, which is placed in cerr, is included in
your error message.



First  |  Prev  | 
Pages: 1 2 3
Prev: sending email with smtp package
Next: Xming X11 server and fullscreen mode