# intersection matches for empty string

**URL:** <https://forum.ansible.com/t/intersection-matches-for-empty-string/12547>\
**Category:** Ansible Project\
**Created:** [March 21, 2013, 5:07am UTC](https://forum.ansible.com/t/intersection-matches-for-empty-string/12547 "2013-03-21T05:07:46Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![kahlil.hodgson](https://avatars.discourse-cdn.com/v4/letter/k/b9bd4f/32.png) [@kahlil.hodgson](https://forum.ansible.com/u/kahlil.hodgson)\
**Post date:** [March 21, 2013, 5:07am UTC](https://forum.ansible.com/t/intersection-matches-for-empty-string/12547/1 "2013-03-21T05:07:46Z")

</div>

I've been playing with intersection (&) and negation (!) matches a bit lately. All very cool -- allowing me to target subsets of groups both inside a playbook and with the --limit command line option.

I'm looking at the code responsible and wondering at the intended semantics if the token following the magic symbols & and ! is empty.  
For example:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ansible-playbook test.yml --list-host --limit 'all:'

give me all hosts (all hosts plus the hosts in the group/host ''),

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ansible-playbook test.yml --list-host --limit 'all:!'

gives me all hosts (all hosts except the hosts in the group/host ''),

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ansible-playbook test.yml --list-host --limit 'all:&'

gives me no hosts (all hosts that are also in the group/host '').

This is all logically correct, but I'm wondering if it is what people expect. The first two cases suggest (incorrectly) that the empty string is being ignored, and intuitively I expected the last case to give me all hosts as well.

Consider also playbooks with either of the following lines

&nbsp;&nbsp;hosts: my\_group:!$constraint

&nbsp;&nbsp;hosts: my\_group:&$constraint

If $constraint is '', then the first runs on all hosts in my\_group, and the second wont run at all.

Should a constraint marker without a token be an error/warning since it is probably not what the user intended? Should the nonsensical pattern be silently dropped?

Thoughts?

K

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [March 21, 2013, 12:30pm UTC](https://forum.ansible.com/t/intersection-matches-for-empty-string/12547/2 "2013-03-21T12:30:14Z")

</div>

It's doing that because there is no group named empty string.

I suppose the question is can "&" and "!" be used to prefix something  
other than a group (like a host) and they can.

It's just like you can do:

hosts: fooGroup:barGroupThatDoesNotExist

and it does not yell at you about barGroupThatDoesNotExist, because  
that could be a pattern, or something that may exist in another  
inventory file.

I think it's not-super-critical as you have listed above, unless you  
find yourself accidentally doing that too much, because we also allow  
group names that don't match the inventory (by design).

--Michael

---

<div class="post-metadata">

**Author:** ![kahlil.hodgson](https://avatars.discourse-cdn.com/v4/letter/k/b9bd4f/32.png) [@kahlil.hodgson](https://forum.ansible.com/u/kahlil.hodgson)\
**Post date:** [March 21, 2013, 9:02pm UTC](https://forum.ansible.com/t/intersection-matches-for-empty-string/12547/3 "2013-03-21T21:02:48Z")

</div>

> It's just like you can do:
> 
> hosts: fooGroup:barGroupThatDoesNotExist
> 
> and it does not yell at you about barGroupThatDoesNotExist, because  
> that could be a pattern, or something that may exist in another  
> inventory file.

Good point.

> I think it's not-super-critical as you have listed above, unless you  
> find yourself accidentally doing that too much, because we also allow  
> group names that don't match the inventory (by design).

After describing the problem and thinking a bit more I came to the same  
conclusion. The better way of achieving what I wanted ended up being

&nbsp;&nbsp;host: mygroup:$contraint

in the included file, and

&nbsp;&nbsp;- include: ../myapp/update.yml constraint='&prod:&webserver'

in the main playbook, which ends up being more explicit and flexible.

Thanks for all you fantastic work with Ansible and best of luck with AnsibleWorks.

Cheers,

Kal