From: "Lukáš Doktor" <ldoktor@redhat.com>
To: Michael Goldish <mgoldish@redhat.com>
Cc: KVM list <kvm@vger.kernel.org>
Subject: Re: [KVM_AUTOTEST][RFC] pre_command chaining
Date: Mon, 13 Jul 2009 09:40:58 +0200 [thread overview]
Message-ID: <4A5AE50A.2090400@redhat.com> (raw)
In-Reply-To: <2062114795.286811247239674709.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
Hi Michael,
you are right, it is possible. But if I specify "pre_command = true" at
the top of my config file, this command will be executed even if no
additional command is added into the queue. (tests with pre_commands are
not selected)
That is my reason why I'd like to see this two lines change into the
framework.
Still you are right that it's basically a "cosmetic" modification for
simplification the config file.
Dne 10.7.2009 17:27, Michael Goldish napsal(a):
> ----- "Lukáš Doktor"<ldoktor@redhat.com> wrote:
>
>> Hi,
>>
>> the way how kvm_autotest currently handle pre_command/post_command it
>> don't allow to specify more than one command. BASH can handle this
>> itself with a small change in the framework , as shown in the
>> attachment.
>
> Why do you say the framework doesn't allow chaining pre_commands?
> What's wrong with:
> pre_command = "command0"
> pre_command += "&& command1"
> pre_command += "&& command2"
>
>> In .cfg file we just change variable from:
>> pre_command = "command"
>> to:
>> pre_commane += "command&&"
>> produce:
>> $(command&& true)
>>
>> Framework adds the last command true, which enclose whole command.
>> This
>> way we can chain infinite pre/post_commands without losing the return
>>
>> value (if something go wrong, other commands are not executed and
>> return
>> value is preserve.
>>
>> example:
>> in cfg:
>> pre_command += "echo A&&"
>> pre_command += "echo B&&"
>> pre_command += "echo C&&"
>> framework params.get("pre_command"):
>> "echo A&& echo B&& echo C&&"
>> framework process_command execute on the host:
>> "echo A&& echo B&& echo C&& true"
>>
>> regards,
>> Lukáš Doktor
>
> In any case, the proposed solution does not allow the user to use
> pre_command in the most straightforward way:
> pre_command = "command"
> because that would get translated into:
> "command true"
> So the user must append&& to the command, which makes little sense.
>
> There could be other solutions, like
>
> 1. Specifying "pre_command = true" at the top of the config file, and
> then using:
> pre_command += "&& command0"
> pre_command += "&& command1"
>
> "pre_command = command" will also work fine in this case.
>
> 2. Removing the final "&&" from the command, if any, so that if the
> user enters:
> pre_command = "command0&&"
> pre_command += "command1&&"
> the framework will run:
> "command0&& command1" instead of "command0&& command1&&".
>
> In any case, can you provide an example where it's impossible or
> difficult to do command chaining without changing the framework?
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-07-13 7:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1691222823.286001247239165845.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-07-10 15:27 ` [KVM_AUTOTEST][RFC] pre_command chaining Michael Goldish
2009-07-13 7:40 ` Lukáš Doktor [this message]
2009-07-10 11:35 Lukáš Doktor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A5AE50A.2090400@redhat.com \
--to=ldoktor@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mgoldish@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox