Looking through the debugger |
expect-lite has had an integrated debugger, called with *INTERACT, since version 4.0 (Oct 2010).The expect-lite debugger allows you to:
- all the standard debugger stuff: step, skip, view variables
- type commands directly to the device/host the script is connected to
- execute arbitrary lines of expect-lite script (copy/paste uses this as well)
IDE: Help
Key Action
---- ------
<esc>s Step
<esc>k sKip next step
<esc>c Continue
<esc>v show Vars
<esc>e show Env
<esc>0to9 Show N next lines of script
<esc>-1to-9 Show N previous lines of script
ctrl+D Quit & Exit expect-lite
<esc>h this Help
The debugger is like a window to the device being automated. Once in a breakpoint, the debugger silently steps aside, and allows you to type directly to the device. Perhaps you aren't getting the response you expected, or the device wasn't configured as you had expected. You can fix it while in the middle of your script.
The debugger silently watches what you type, and decides if the text is for the device, or is it an expect-lite command it must execute. How does it do this? Mostly pretty well.
Typing expect-lite commands in the debugger
You may have noticed that expect-lite commands start with a punctuation character like '>', '<', '?', '@', or ';'. The debugger watches for these characters at the beginning of a line. But there are some tweaks to prevent the debugger from accidentally grabbing a line that was intended for the device. These are limitations only when typing in the debugger, and are not required when executing the expect-lite script.
- >send this There must be no space between > and the text to be sent
- ; comment There must be a space between the semi-colon and the comment
- ?if condition... When using an IF statement in the debugger then the optional 'if' must be used, there are just too many question marks in normal text
- $var=value Variable assignments must have an equals sign (no spaces)
- no white space before the expect-lite command (punctuation)
*SHOW ENV
The biggest improvement to the debugger in version 4.8.0, is *SHOW ENV. Similar to *SHOW VARS, the expect-lite environment consists of a list of directives which are enabled/disabled, such as *INFO, and *TIMESTAMP, as well as ones with values like user defined prompt, and the infinite loop count (*INFINITELOOP). Lastly, *SHOW ENV will display any shell environment variables which begin with EL_.
$ DEBUG Info: Printing expect-lite directives/environment
Environment: Value:
CURRENT_FORK_SESSION default
DEBUG off
DVPROMPT on
EOLS LF
EXP_INFO on
FAIL_SCRIPT fail_test.inc
INFINTE_LOOP_COUNT 5000
INFO on
LOG off
LOG_EXT .log
NOFAIL 2
NOINCLUDE off
NOINTERACT off
REMOTE_SHELL none
TIMESTAMP off
USER_DEFINED_PROMPT .*$ $
WARN on
fuzzy_range 10
timeout 2
EL_CONNECT_METHOD ssh_key
EL_REMOTE_HOST localhost
Just as you can start a new shell, by typing 'bash' or 'csh' at the prompt. There is an included example called 'el_shell.elt' which you can use to create an expect-lite shell. It is a simple script which just drops you into the debugger. From there, you can type regular linux commands (or cygwin linux-like commands), expect-lite commands, or explore the debugger help with <esc>h.
Doughnut Scripts
I find I often create a doughnut script, a script with a hole in the middle. I use this to have a script set up my environment, then drop to the debugger, allowing me to plunk around, then when I am done, I exit the debugger (with '+++'), and the script cleans up. I call this automation assist. It doesn't do everything, but it allows me to explore/test faster than doing it all by hand.
The debugger command detection isn't perfect, but it works pretty well. Sometimes you may find a smudge or a dirty spot on the debugger window, but hopefully, it will be clear enough to see that expect-lite is automation for the rest of us.
No comments:
Post a Comment