I guess I'm getting way beyond my expertise here, but is it possible to specify a shell when you SSH? Instead of taking the default shell?
I tried default_run_options[:shell]=false in my real capfile, but of course that led to shell syntax errors in the builtin Rails recipes (specifically deploy:rollback) because it's using tcsh, not sh anymore. On 19 May, 12:15, Jamis Buck <[email protected]> wrote: > I'll bet it's tcsh. Capistrano calls "sh -c ..." specifically to work > around issues with non-posix shells; it sure sucks when those non-posix > shells make it impossible to make posix calls. > > I'm afraid it's looking like your only option is going to be to change > your default shell to something posix. :( > > - Jamis > > On 5/19/09 12:47 PM, Scott Johnson wrote: > > > Adding :shell => false to the run params does work. But I would still > > like to resolve this. I'm probably not the last person that will > > encounter this problem with Capistrano, and while it's evidently not > > the tool's fault, if there's something Cap can do to avoid it, that > > would be nice. > > > I think it's clearly something with my environment. I tried the sh -c > > command on all the bash versions I could find, all using the same > > environment, and they all failed. > > > 3.1.17(1)-release (i686-redhat-linux-gnu) > > 3.1.7(1)-release (x86_64-redhat-linux-gnu) > > 2.0.5a.0(1)-release (i686-pc-linux-gnu) > > 3.00.15(1)-release (i686-redhat-linux-gnu) > > > But when I ran at home (WinXP, msysGit bash, with the default msysGit > > environment), it worked fine. > > > One difference is the shell I'm launching from: tcsh (my default shell > > on those systems) in all the broken cases. When I launch sh -c from > > bash itself, it works. Perhaps tcsh is mangling the command before > > invoking sh? Here's a clue: > > > % echo "foo is \`date\`" > > foo is \ > > > I don't understand that. > > > On 19 May, 10:39, Jamis Buck<[email protected]> wrote: > >> Maybe it's something with that version of GNU bash? This one works for me: > > >> $ sh --version > >> sh --version > >> GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0) > >> Copyright (C) 2005 Free Software Foundation, Inc. > > >> It also works fine with the posix shell in Ubuntu (not sure which > >> version of Ubuntu, but fairly recent). > > >> Also, I think I led you astray with the set(:shell, false) nonsense. The > >> correct way to set that is either this: > > >> run("echo today is `date`", :shell => false) > > >> or > > >> default_run_options[:shell] = false > > >> The former only applies to that run invocation; the latter applies > >> globally to all run invocations. > > >> - Jamis > > >> On 5/19/09 11:32 AM, Scott Johnson wrote: > > >>> Getting closer! Something is wacked with my shell: > >>> % sh -c "echo today is \`date\`" > >>> today is > >>> % sh --version > >>> GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu) > >>> Copyright (C) 2005 Free Software Foundation, Inc. > >>> Perhaps I have some environment variable set wrong or something? > >>> Jamis, the capfile I posted in my original message is the complete > >>> capfile. I tried adding set :shell, false and it made no difference. > >>> I suppose the change I made to command.rb is incorrect because the > >>> backticked command will be run locally instead of remotely. (Right?) > >>> On 19 May, 09:47, Jamis Buck<[email protected]> wrote: > >>>> The reason it is escaped is because Capistrano invokes the command via > >>>> 'sh' (by default). E.g., the following run command: > >>>> run "echo today is `date`" > >>>> Gets translated into the following shell command: > >>>> sh -c "echo today is \`date\`" > >>>> The backticks need to be escaped so that they get evaluated by the inner > >>>> shell, and not the outer shell. > >>>> That said, what does the rest of your capfile look like? Are you setting > >>>> :shell anywhere? What version of the posix shell do you have on your > >>>> remote host? > >>>> You might also try setting :shell to false, so that all commands are > >>>> invoked directly: > >>>> set :shell, false > >>>> That way, commands will be run without wrapping them in a "sh -c ..." > >>>> call. > >>>> - Jamis > >>>> On 5/19/09 10:33 AM, Scott Johnson wrote: > >>>>> I don't believe it is a permissions thing. I can run the same command > >>>>> not in backticks and it works. I can run the backticked command > >>>>> directly (not through Capistrano) and it works as expected: > >>>>> date is Tue May 19 09:25:51 PDT 2009 so there > >>>>> And I can edit Capistrano's source as described above and get it to > >>>>> work. > >>>>> There is something going on with Capistrano's escaping of the > >>>>> backticks that I don't understand. Why is it necessary on every > >>>>> computer except mine to escape the backticks? And why, when they are > >>>>> escaped on my machine, does the backticked command simply disappear > >>>>> without a trace? > >>>>> I can't imagine what could be so different on my machine. I realize > >>>>> I'm running an old Fedora, but things like backticks and shell escape > >>>>> characters haven't changed in 25 years. > >>>>> On 19 May, 08:10, Lee Hambley<[email protected]> wrote: > >>>>>> Scott, > >>>>>> Hate to respond with a classic `worksforme` -- may it be that your user > >>>>>> (humor me) doesn't have access to do any of the things you are asking, > >>>>>> try > >>>>>> something like run('touch `echo date`') or similar. > >>>>>> To save potential email formatting issues, please post the code, > >>>>>> output and > >>>>>> error all in a gist/pastie and post us the links. > >>>>>> - Lee > >>>>>> 2009/5/19 Scott Johnson<[email protected]> > >>>>>>> No difference. Not only is the output of the backticked command not > >>>>>>> getting into the string, the command itself is never being run. I can > >>>>>>> replace the command with `touch file.txt` and that file is never > >>>>>>> created. > >>>>>>> On 19 May, 01:26, Lee Hambley<[email protected]> wrote: > >>>>>>>> Try, > >>>>>>>> task :foo, :hosts => "my.host.com" do > >>>>>>>> run "echo date is `cat /bin/date` so there" > >>>>>>>> end > >>>>>>>> 2009/5/19 Scott Johnson<[email protected]> > >>>>>>>>> I have a run command that uses shell backticks, yet the command in > >>>>>>>>> the > >>>>>>>>> backticks never runs and I get an empty string instead of the output > >>>>>>>>> of the command. > >>>>>>>>> My Capfile: > >>>>>>>>> task :foo, :hosts => "my.host.com" do > >>>>>>>>> run "echo date is `/bin/date` so there" > >>>>>>>>> end > >>>>>>>>> Output from running 'cap foo': > >>>>>>>>> * executing 'foo' > >>>>>>>>> * executing "echo date is `/bin/date` so there" > >>>>>>>>> servers: ["my.host.com"] > >>>>>>>>> [my.host.com] executing command > >>>>>>>>> ** [out :: my.host.com] date is so there > >>>>>>>>> command finished > >>>>>>>>> Bizarre. > >>>>>>>>> I'm running cap 2.5.5 on Fedora Core release 6 with Ruby 1.8.7. The > >>>>>>>>> local and remote machine are the same (ie, I'm launching cap from > >>>>>>>>> my.host.com). > >>>>>>>>> If I edit line 212 of lib/capistrano/command.rb (that escapes > >>>>>>>>> certain > >>>>>>>>> special characters in the command) and remove the backtick from the > >>>>>>>>> gsub args, it works. But I somehow doubt this is the proper > >>>>>>>>> solution, > >>>>>>>>> since I seem to be the only one having this problem. --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
