.. versionchanged:: 2018.3.0
        Added ``with_pillar`` argument

    Execute ``fun`` with the given ``args`` and ``kwargs``.  Parameter ``fun``
    should be the string :ref:`name <all-salt.modules>` of the execution module
    to call.

    .. note::
        Execution modules will be loaded *every time* this function is called.
        Additionally, keep in mind that since runners execute on the master,
        custom execution modules will need to be synced to the master using
        :py:func:`salt-run saltutil.sync_modules
        <salt.runners.saltutil.sync_modules>`, otherwise they will not be
        available.

    with_pillar : False
        If ``True``, pillar data will be compiled for the master

        .. note::
            To target the master in the pillar top file, keep in mind that the
            default ``id`` for the master is ``<hostname>_master``. This can be
            overridden by setting an ``id`` configuration parameter in the
            master config file.

    CLI example:

    .. code-block:: bash

        salt-run salt.cmd test.ping
        # call functions with arguments and keyword arguments
        salt-run salt.cmd test.arg 1 2 3 a=1
        salt-run salt.cmd mymod.myfunc with_pillar=True

def cmd(fun, *args, **kwargs):
    '''
    .. versionchanged:: 2018.3.0
        Added ``with_pillar`` argument

    Execute ``fun`` with the given ``args`` and ``kwargs``.  Parameter ``fun``
    should be the string :ref:`name <all-salt.modules>` of the execution module
    to call.

    .. note::
        Execution modules will be loaded *every time* this function is called.
        Additionally, keep in mind that since runners execute on the master,
        custom execution modules will need to be synced to the master using
        :py:func:`salt-run saltutil.sync_modules
        <salt.runners.saltutil.sync_modules>`, otherwise they will not be
        available.

    with_pillar : False
        If ``True``, pillar data will be compiled for the master

        .. note::
            To target the master in the pillar top file, keep in mind that the
            default ``id`` for the master is ``<hostname>_master``. This can be
            overridden by setting an ``id`` configuration parameter in the
            master config file.

    CLI example:

    .. code-block:: bash

        salt-run salt.cmd test.ping
        # call functions with arguments and keyword arguments
        salt-run salt.cmd test.arg 1 2 3 a=1
        salt-run salt.cmd mymod.myfunc with_pillar=True
    '''
    log.debug('Called salt.cmd runner with minion function %s', fun)

    kwargs = salt.utils.args.clean_kwargs(**kwargs)
    with_pillar = kwargs.pop('with_pillar', False)

    opts = copy.deepcopy(__opts__)
    # try to only load grains if we need to, it may already exist from other contexts (e.g., pillar)
    if 'grains' not in opts:
        _, grains, _ = salt.utils.minions.get_minion_data(__opts__['id'], __opts__)
        if grains:
            opts['grains'] = grains
        else:
            opts['grains'] = salt.loader.grains(opts)

    if with_pillar:
        opts['pillar'] = salt.pillar.get_pillar(
            opts,
            opts['grains'],
            opts['id'],
            saltenv=opts['saltenv'],
            pillarenv=opts.get('pillarenv')).compile_pillar()
    else:
        opts['pillar'] = {}

    functions = salt.loader.minion_mods(
        opts,
        utils=salt.loader.utils(opts),
        context=__context__)

    return functions[fun](*args, **kwargs) \
        if fun in functions \
        else '\'{0}\' is not available.'.format(fun)