Rex
Rex copied to clipboard
Bug: rex -H host1 -H host2 task
If you run this command:
rex -H host1 -H host2 task
You get the following error:
No group host2 defined.
rex -H “host1 host2” task this is the right way
@bollwarm: you're right, but having a group error in this case still sounds a bit weird ^^
On reddit, there's a thread pointing out that rex is pretty inconsistent here: https://www.reddit.com/r/linuxadmin/comments/36263g/has_anyone_used_rexify_for_configuration/
I was hoping this issue was both about the error and to resolve the fact that -H host1 -H host2
doesn't work.
@ehuelsmann: thanks for the link! It's interesting that an inconsistency has been described at such lengths on reddit instead of notifying us :) It's also interesting, that so far it wasn't a big problem in practice - I guess that's because the model in Rex focuses on registering tasks with host(s) or groups of hosts, instead of on ad-hoc command running (needs to be documented, right :). Looks like this has been shifted, and there's more and more demand for that. Which is totally OK, the world is in constant change :)
Nevertheless, I'll open an issue about it, and I think I'm going to answer to the reddit thread as well. It's a good idea to improve the argument handling, to cover more people's expectations, and also to document the rex task model more.
Another downside to space delimited host arguments (or any for that matter) is that if you need to create a wrapper script for rex, and you end up calling "rex $@", you lose the quotes so it thinks hosts are tasks. For example, if you use Perlbrew in Shell Scripts and you pass along your wrapper script arguments, rex gets confused:
#!/bin/bash
# filename: ~/bin/myservice.pl
## These 3 lines are mandatory.
export PERLBREW_ROOT=~/perl5/perlbrew
export PERLBREW_HOME=/tmp/.perlbrew
source ${PERLBREW_ROOT}/etc/bashrc
perlbrew use perl-5.23.6
cd ~/rex/services/myservice
rex $@
> myservice.pl -H "one.localhost two.localhost" uptime
[2016-01-12 10:00:19] ERROR - No task named 'two.localhost' found. Task names are case sensitive and the module delimiter is a single colon.
In short, it would be much easier to just specify -H host1 -H host2
than trying to have your wrapper script escape quotes on -H "host1 host2"
.
The docs for the rex script should mention the need for quotes when using -H with multiple hosts.
The docs for the rex script should mention the need for quotes when using -H with multiple hosts.
On one hand, this issue is originally about considering to support -H host1 -H host2
notation to pass multiple hosts as targets (and perhaps prevent a misleading error message about groups). It certainly sounds like a good idea, but apparently nobody felt strongly enough about it so far to actually invest into tests and implementation.
@mrmuskrat: On the other hand, it sounds like you have more specific expectations about where and how the need for quoting could be better documented. Could you share a specific proposal, please? It may be best to discuss it separately from this old different thread, though. For example in a discussion or other support channels).
More context about quoting arguments with spaces
One aspect around this question is that how to quote arguments which contain spaces is primarily a concern of the given shell used to run the rex command with such arguments. That may make it tricky to provide an example which is universally true and makes everyone happy for all shells across all operating systems that may be used to run rex.
I believe that's part of the original motivation of simply documenting it as "space delimited" in the POD/man/help output, and then let the user act on it according to their own environment at hand.