ssh command assumes the user's shell on the server is bashish

[chetstone]

I set up my server with tcsh as my login shell (OK, I'm a geezer!). When I do mina setup, I get a string of errors like:

Too many ('s.
Invalid null command.
Invalid null command.
Invalid null command.

-----> Done.
Too many )'s.

Looking at the code for ssh, I see it is invoked like ssh server [options] -- #!/usr/bin/env bash \n# etc..
I don't understand exactly what -- means on the ssh command line. My man page for ssh (MacOSX 10.9) does not mention it. But apparently the receiving process does not recognize the shebang and just drops it as a comment, trying to execute the rest of the commands with the default login shell.

I encountered this on a server running SmartOS (Solaris) but just confirmed the same thing happens on an Ubuntu server.

So far the only workaround I can think of is to create a file with the commands, scp it to the server and execute it with ssh. I realize this is not very satisfactory but can't think of anything else at the moment.

[rstacruz]

-- is a typical convention to allow you to pass the rest of the arguments as arguments. I think another alternative is to echo "contents here" | ssh <args>.

If anyone can contribute a patch on this, it'd be very well appreciated!

[chetstone]

Thanks for the reply. I've tried a couple of things but haven't found a good way around it.

First, I discovered that the shebang line is not really in the script --- it's only in the simulated output. (So there's a workaround: run with -S, capture the output, copy it to the server and run it there.) I did try adding it to the front of the script, but as I expected, it had no effect.

Then I tried

code = "#{this.ssh_command} -- /usr/bin/env bash -c #{script}"

This doesn't work --- it invokes bash but only for the first line of the script. The remaining lines are interpreted by the login shell. I tried quoting the script like this:

code = "#{this.ssh_command} -- /usr/bin/env bash -c \'#{script}"\'

but that confused the local shell and indeed the shellwords documentation warns against this.
I tried running shellwords on the script twice. That didn't work --- the remote shell (the login or csh shell) doesn't understand the quoting it gets. I suppose it might work if shellwords had a csh mode: quote first with csh for the remote shell and again with sh mode for the local shell. But that would not be ideal anyway because you would have to explicitly tell mina that your remote shell is csh-ish.

I also tried

code = "cat #{script} | #{this.ssh_command} -- /usr/bin/env bash -s"

but this failed with a message from ssh that it could not allocate the pty requested by -t because its input was not STDIN. Now this might work if you could force the pty allocation, depending on what mina needs to do with it.

At that point though, I decided this was an opportunity for me now to make myself a comfortable new home in Bashland. A week ago I didn't even know that bash had aliases, let alone pretty much everything you need to emulate the tcsh environment I've been working in for 25 years.

Since mina's been around for a couple of years and I'm the first that's noticed this, it does not seem to be a priority item --- I may have been the only geezer left still using tcsh!

[rstacruz]

Sorry, man. I'd love to account for this, but as you've mentioned, there isn't an obvious workaround right now.

Thank you so much for doing the research on this!