Re: [PATCH OSSTEST] make-flight: Support specifying a mini-os tree+revision

[Ian Campbell <ian.campbell@citrix.com>]

On Fri, 2016-01-15 at 17:07 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST] make-flight: Support specifying
> a mini-os tree+revision"):
> > On Fri, 2015-12-11 at 15:16 +0000, Ian Jackson wrote:
> >     unable to determine vcs
> >     bash: line 5: fail: command not found
> > 
> > I'm not sure if this is a bug (i.e. it was intended to be "echo fail")
> > or
> > if it is deliberately using  a non-existent command (which seems risky
> > to
> > me).
> 
> It's deliberately using the command `fail' which is supposed to be in
> scope and fail.  I think this is harmless.

Where does that command come into scope from?

Are you thinking of the sub fail() in Perl (from Osstest::TestSupport)?

The fail quoted above is from:
    sub dir_identify_vcs ($$) {
        my ($ho,$dir) = @_;
        return target_cmd_output($ho, <<END);
            set -e
            if ! test -e $dir; then echo none; exit 0; fi
            cd $dir
            (test -e .git && echo git) ||
            (test -d .hg && echo hg) ||
            (echo >&2 'unable to determine vcs'; fail)
    END
    }

i.e. it is in a shell snippet run on the target. I'm not sure where fail
would come into scope in that context. I don't see it in the tcmd
infrastructure.

> > All the other store_revisions refer to the symlink rather than the
> > -remote
> > which is the actual clone (when one is made), so I don't think
> > s#extras/mini-os#extras/mini-os-remote# is the answer. Perhaps "fail"
> > should become "echo fail" and store_revision should treat that like it
> > does
> > fail (which is to accept it if $optional).
> 
> That would be tolerable, I think.  It's probably the best answer.

I'll wait and check I'm not terribly confused above before moving in this
direction.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel