Use /bin/bash when using Bash specific shell commands

[allenwyma]

I have a bit of an issue when trying to use capistrano/sshkit. Our user account is setup to use tsch for legacy reasons. I can try to talk to them about changing to bash, but would have better luck (and could probably help others), if we can just run bash specific commands using /bin/bash or we are able to set the bash shell using some kind of variable (set :bash_shell, '/usr/local/bin/bash')?

PS wasn't sure to put this on here or Capistrano, but I think here would make a bit more sense.

[mattbrictson]

I'm not sure this is a feature we can support. If you could propose some pseudocode or explain what the general strategy would be for building this, then I'll give it some more consideration. Off the top of my head I don't know how to do it.

[mattbrictson]

I don't think what you're asking is possible, at least according to this Stack Overflow answer: http://serverfault.com/questions/162018/force-ssh-to-use-a-specific-shell

I'll leave this issue open for the time being just in case anyone else has ideas of how this could be done.

[allenwyma]

@mattbrictson can't we just specifically call bash command and use -c ? Cause we are running commands using the env right?

[allenwyma]

@mattbrictson how about this: http://www.cyberciti.biz/faq/unix-linux-execute-command-using-ssh/

## su syntax ##
ssh user@nas01 su -c "/bin/bash-c 'bash statements'"

# RHEL/CentOS specific #
ssh user@nas01 su --session-command="/bin/bash-c 'bash statements'"
ssh [email protected] su --session-command="/bin/bash-c 'bash statements'"

[mattbrictson]

Hmm. Yes, bash -c can do what you want, but you would have to rewrite your tasks to use it.

As a more general solution, we would have to both prefix every SSHKit command with bash -c, and perform all necessary escaping on the original command so that it can be passed as the value for -c.

The escaping would be very tricky to get right, especially if different shells having different escaping rules.

Honestly I think it might be easier just to convince your user to change their default shell to bash. 😄

[allenwyma]

@mattbrictson you would be surprised how much prefixing would be easier to do, than to get them to move legacy scripts. i think history was starting off with solarius the moved to redhat and didn't want to change up their workflow.

[mattbrictson]

I've decided that this is not something that I am willing to implement and support myself. However I will leave this issue open in case someone comes forward with an implementation plan and then a PR.

My hunch is that the best way to address this long term is to expand SSHKit's command-rewriting system. Currently we have ways for adding prefixes, but no way for the entire command to be rewritten (as would be necessary to perform the proper escaping). If a rewriting extension point is added, then you could plug in whatever logic you need.

[allenwyma]

@mattbrictson can you leave more notes on this? I may take a look at this if it comes to it. I tried to look at sshkit and it's quite complex for me at first glance. would need to really follow more on how it all works.

[mattbrictson]

command_map.rb is where the current rewriting logic takes place, so I would start there. I also recommend searching the issues on GitHub to see historically what bugs, feature requests, and PRs have been logged regarding the command map. That would give you some more context. Good luck!

[kperry42]

...and here, I thought converting from Capistrano 2.x to 3 wouldn't be all that hard. Is the requirement to have bash as your login shell even documented anywhere? It seems like bad design to force this. A tool like this should be agnostic about such things. I too have legacy reasons for using an account that has tcsh as its login shell. Not sure what will break if I change it, and I really don't have time to dig into all that. Sigh, I may just have to stay on Cap 2.x forever...

[allenwyma]

@kperry42 cap2 would work? hmm might need to try that.

[mattbrictson]

Is the requirement to have bash as your login shell even documented anywhere?

Which feature of SSHKit or Capistrano requires bash? Please log this as an issue so we can either address it in the documentation or change it to remove the hard requirement. Thanks!

[kperry42]

@HangingClowns - Yes, I've been working with Cap 2.15.4 just fine for a long time. It's just when I tried upgrading to Cap 3 that I ran into shell compatibility problems.

@mattbrictson Thanks, I've logged an issue - capistrano/capistrano issue 1870