Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ansible_shell_interpreter, or some other way to globally set the executable used by the shell module #35446

Closed
wknapik opened this issue Jan 29, 2018 · 8 comments
Labels
affects_2.5 This issue/PR affects Ansible v2.5 feature This issue/PR relates to a feature request. module This issue/PR relates to a module. support:core This issue/PR relates to code supported by the Ansible Engineering Team.

Comments

@wknapik
Copy link
Contributor

wknapik commented Jan 29, 2018

ISSUE TYPE

Feature Idea

COMPONENT NAME

shell

ANSIBLE VERSION
ansible 2.5.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/home/foo/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.14 (default, Sep 20 2017, 01:25:59) [GCC 7.2.0]

2.5.0.34964.01091cddf6-1

CONFIGURATION

DEFAULT_STDOUT_CALLBACK(/etc/ansible/ansible.cfg) = debug

OS / ENVIRONMENT

N/A

SUMMARY

There should be a way to set the preferred shell executable globally, instead of having to do it in every single shell module invocation.

I have a bunch of roles here with a total of 39 shell tasks. Adding args: executable=bash in 39 places is just... wrong.

Also, it would be great to be able to set it to /usr/bin/env bash, instead of a path, like /usr/bin/bash, etc., since those vary between systems.

STEPS TO REPRODUCE

N/A

EXPECTED RESULTS

One global setting.

ACTUAL RESULTS

No global setting.

@ansibot
Copy link
Contributor

ansibot commented Jan 29, 2018

Files identified in the description:

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

@ansibot ansibot added affects_2.5 This issue/PR affects Ansible v2.5 feature_idea module This issue/PR relates to a module. needs_triage Needs a first human triage before being processed. support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Jan 29, 2018
@alikins
Copy link
Contributor

alikins commented Jan 29, 2018

There is a ansible_shell_executable (http://docs.ansible.com/ansible/latest/intro_inventory.html#list-of-behavioral-inventory-parameters). Would that work for your use case? If not, what is missing?

See also #24169 and related pr #31361 (and for more context, also the now reverted #24177

@alikins alikins added needs_info This issue requires further information. Please answer any outstanding questions. and removed needs_triage Needs a first human triage before being processed. labels Jan 29, 2018
@wknapik
Copy link
Contributor Author

wknapik commented Jan 31, 2018

Oh wow. I searched for this for quite a while and couldn't find it - not in the docs, not on google, not on irc...

Yes, ansible_shell_executable seems to be what I was looking for.

Why the inconsistent naming though ?

Also, could info about ansible_shell_executable be added here https://docs.ansible.com/ansible/latest/shell_module.html ?

Thanks!

@ansibot ansibot removed the needs_info This issue requires further information. Please answer any outstanding questions. label Jan 31, 2018
@bcoca
Copy link
Member

bcoca commented Feb 5, 2018

@wknapik that is different, the setting controls the shell used for executing modules, not the shell used by the shell module.

@wknapik
Copy link
Contributor Author

wknapik commented Feb 6, 2018

@bcoca - well, you say that...

% ansible -m shell -a 'echo $0' localhost
localhost | SUCCESS | rc=0 >>
/bin/sh
% ansible -m shell -a 'echo $0' -e ansible_shell_executable=bash localhost
localhost | SUCCESS | rc=0 >>
bash
%

Works for me.

@bcoca
Copy link
Member

bcoca commented Feb 6, 2018

i did not say it wouldn't work, but it is not 'on purpose', but a side effect, it was not meant as a default for the 'shell' module just what to use when executing modules.

@wknapik
Copy link
Contributor Author

wknapik commented Feb 6, 2018

To me, that calls for the introduction of ansible_shell_interpreter, as I originally suggested.

If the current effect of ansible_shell_executable on the shell module were to change, the users who rely on this behavior would have to be given a reasonable way out...

I suppose few would actually need to execute all modules with shell X and use shell Y with the shell module, but for those few, ansible_shell_interpreter would be the only solution.

@bcoca
Copy link
Member

bcoca commented Feb 6, 2018

this is a subset of 'defaults for modules' which we do not have a facility for.

closing as dupe/subset of ansible/proposals#81

@bcoca bcoca closed this as completed Feb 6, 2018
@ansibot ansibot added feature This issue/PR relates to a feature request. and removed feature_idea labels Mar 3, 2018
@ansible ansible locked and limited conversation to collaborators Apr 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.5 This issue/PR affects Ansible v2.5 feature This issue/PR relates to a feature request. module This issue/PR relates to a module. support:core This issue/PR relates to code supported by the Ansible Engineering Team.
Projects
None yet
Development

No branches or pull requests

4 participants