On Tue, Aug 11, 2009 at 09:27:17AM -0400, Michael Goldish wrote:
>
> ----- "Yolkfull Chow" <yzhou@xxxxxxxxxx> wrote:
>
> > On Tue, Aug 11, 2009 at 03:10:42PM +0300, Michael Goldish wrote:
> > > Currently the test only logs in, runs a given script and fails if
> > the script
> > > takes too long to exit or if its exit status is nonzero.
> > >
> > > The test expects these parameters:
> > > autoit_binary: Path to AutoIt binary in the guest.
> > > autoit_script: Path to script in the host.
> > > autoit_script_params: Command line parameters to send to the
> > script.
> > > autoit_script_timeout: The time duration (in seconds) to wait for
> > the script to
> > > exit.
> > >
> > > The test code can be extended later to add more features.
> > >
> > > Signed-off-by: Michael Goldish <mgoldish@xxxxxxxxxx>
> > > ---
> > > client/tests/kvm/kvm.py | 1 +
> > > client/tests/kvm/kvm_tests.py | 66
> > +++++++++++++++++++++++++++++++++++++++++
> > > 2 files changed, 67 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/client/tests/kvm/kvm.py b/client/tests/kvm/kvm.py
> > > index 070e463..4930e80 100644
> > > --- a/client/tests/kvm/kvm.py
> > > +++ b/client/tests/kvm/kvm.py
> > > @@ -56,6 +56,7 @@ class kvm(test.test):
> > > "linux_s3": test_routine("kvm_tests",
> > "run_linux_s3"),
> > > "stress_boot": test_routine("kvm_tests",
> > "run_stress_boot"),
> > > "timedrift": test_routine("kvm_tests",
> > "run_timedrift"),
> > > + "autoit": test_routine("kvm_tests",
> > "run_autoit"),
> > > }
> > >
> > > # Make it possible to import modules from the test's
> > bindir
> > > diff --git a/client/tests/kvm/kvm_tests.py
> > b/client/tests/kvm/kvm_tests.py
> > > index 9cd01e2..749c1fd 100644
> > > --- a/client/tests/kvm/kvm_tests.py
> > > +++ b/client/tests/kvm/kvm_tests.py
> > > @@ -776,3 +776,69 @@ def run_timedrift(test, params, env):
> > > if drift > drift_threshold_after_rest:
> > > raise error.TestFail("Time drift too large after rest
> > period: %.2f%%"
> > > % drift_total)
> > > +
> > > +
> > > +def run_autoit(test, params, env):
> > > + """
> > > + A wrapper for AutoIt scripts.
> > > +
> > > + 1) Log into a guest.
> > > + 2) Run AutoIt script.
> > > + 3) Wait for script execution to complete.
> > > + 4) Pass/fail according to exit status of script.
> > > +
> > > + @param test: KVM test object.
> > > + @param params: Dictionary with test parameters.
> > > + @param env: Dictionary with the test environment.
> > > + """
> > > + vm = kvm_utils.env_get_vm(env, params.get("main_vm"))
> > > + if not vm:
> > > + raise error.TestError("VM object not found in
> > environment")
> > > + if not vm.is_alive():
> > > + raise error.TestError("VM seems to be dead; Test requires a
> > living VM")
> > > +
> > > + logging.info("Waiting for guest to be up...")
> > > +
> > > + session = kvm_utils.wait_for(vm.remote_login, 240, 0, 2)
> > > + if not session:
> > > + raise error.TestFail("Could not log into guest")
> > > +
> > > + try:
> > > + logging.info("Logged in; starting script...")
> > > +
> > > + # Collect test parameters
> > > + binary = params.get("autoit_binary")
> > > + script = params.get("autoit_script")
> > > + script_params = params.get("autoit_script_params", "")
> > > + timeout = float(params.get("autoit_script_timeout", 600))
> > > +
> > > + # Send AutoIt script to guest (this code will be replaced
> > once we
> > > + # support sending files to Windows guests)
> > > + session.sendline("del script.au3")
> > > + file = open(kvm_utils.get_path(test.bindir, script))
> > > + for line in file.readlines():
> > > + # Insert a '^' before each character
> > > + line = "".join("^" + c for c in line.rstrip())
> > > + if line:
> > > + # Append line to the file
> > > + session.sendline("echo %s>>script.au3" % line)
> > > + file.close()
> > > +
> > > + session.read_up_to_prompt()
> > > +
> > > + command = "cmd /c %s script.au3 %s" % (binary,
> > script_params)
> >
> > Hi Michael, for the problem that execute script in Windows cmd shell,
> > I have some information share with you:
> >
> > Guys in our team had found that the value which `echo %errorlevel%`
> > returns is not always right. It just reflects whether the action to
> > execute the script has been implemented successfully and it ALWAYS
> > return
> > even if errors occur. That means as soon as the script has been
> > started
> > successfully it will return 0 even if error occurred during script
> > running.
>
> You can't issue 'echo %errorlevel%' before the command returns.
> If the command is blocking, i.e. if you have to wait for it to complete,
> like 'dir' or any typical shell command, 'echo %errorlevel%' works just
> fine and reflects the exit status of the command.
>
> If the command returns immediately, like GUI apps (calc, notepad), then
> you should run it using 'cmd /c' like the AutoIt test does.
> cmd will return only when the GUI program terminates, and then you can
> use 'echo %errorlevel%' as usual.
>
> Note that when running a command using 'cmd /c', the following
> 'echo %errorlevel%' indeed does not reflect the exact exit status of the
> command. It can only equal 0 or 1, and it seems that if the command
> exited with an exit status of 0, 'cmd /c' will return 0, and otherwise
> it will return 1. For example, if you run 'cmd /c nosuchcommand' you'll
> get 1, even though running 'nosuchcommand' alone returns 9009.
> This is good enough because we don't care about the exact exit status --
> we just want to know if the script succeeded or not.
>
> > One solution could be use command 'start /wait script.au3' which will
> > let program wait for it to terminate:
> > http://ss64.com/nt/start.html
>
> start /wait doesn't seem to work very well.
> When I run 'start /wait dir', 'dir' is executed in a new cmd window, and
> the window doesn't close until I manually close it.
> If I run 'start /wait nosuchcommand', I get a GUI error message, which
> means I can't do anything else until someone manually clicks OK in that
> error dialog.
>
> 'cmd /c' seems to work fine in all cases, and when testing the AutoIt test
> I found no problems with it.
>
> BTW, I think you should always use 'cmd /c' for GUI programs, even if they
> don't return immediately, because you might not be able to run GUI
> programs at all without it. I'm not sure why, but if you just run 'calc'
> from a remote shell (on WinXP for example), the calculator doesn't appear
> immediately (or ever, sometimes). With 'cmd /c' it always works.
Yes, that's it. Thanks so much for sharing this. :-)
>
> >
> > I have not investigated it enough as well, if any mistake made,
> > please just ignore this reply. ;-)
> >
> >
> > > +
> > > + logging.info("---------------- Script output
> > ----------------")
> > > + status = session.get_command_status(command,
> > > +
> > print_func=logging.info,
> > > + timeout=timeout)
> > > + logging.info("---------------- End of script output
> > ----------------")
> > > +
> > > + if status is None:
> > > + raise error.TestFail("Timeout expired before script
> > execution "
> > > + "completed (or something weird
> > happened)")
> > > + if status != 0:
> > > + raise error.TestFail("Script execution failed")
> > > +
> > > + finally:
> > > + session.close()
> > > --
> > > 1.5.4.1
> > >
> > > _______________________________________________
> > > Autotest mailing list
> > > Autotest@xxxxxxxxxxxxxxx
> > > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
