Thinking a bit more about this, I think it is not a good idea to change from bash:
* Moving to a different shell may massively break the script (that can be complex) what users have built. It can be too painful for the users to update all the scripts to get them working again. * The existing predefined helper functions in the scriptbuilder project assume certain distributions. They rely on apt or yum to install software, for example, and that only works on Debian based or Red Hat/CentOS/Fedoras, etc, and all those distributions come with a bash shell. If someone wants to use a different one, most of those utilities won't work, so the best approach for them would be to build the entire script and run it without wrapping. * If we want to support several shells (and let users configure the one to use) we need to either have the script fragments predefined for each shell, or have a template system that generates the appropriate syntax (something similar to what the ShellToken class does in a very simple way to generate Windows scripts), but I really don't like to rely on this. Apart from introducing a new (and important) challenge to implement (or delegate to an external tool), users would have to "learn" our template system so they can build portable scripts. Given all this points, I think we should not change the current implementation (and don't merge this PR), and stick to bash. If someday a user requests certain features to be available for a different shell (say the AdminAccess related scripts) we can always "translate! that concrete scripts and make them available by other means, or just as a new independent statement. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/150#issuecomment-24700795
