Scott, Thanks - I'll pick those up. - Lee
2009/5/19 Scott Johnson <[email protected]> > > It seems after testing that the solution I discovered last night > (described in the first post, edit command.rb so it won't escape > backticks) is a correct and robust solution. > > * The quoted command is run on the remote host. > > * It works when remote user's default shell is tcsh. > > * It works when remote user's default shell is bash. > > * It works when default_run_options[:shell]=false (though it will then > run tcsh if that's your default shell) > > * It works when default_run_options[:shell] is not set. > > * 'rake test' reports all tests passing. > > I pushed the change to github scottj97/capistrano. > > > On 19 May, 13:30, Jamis Buck <[email protected]> wrote: > > It's only possible if you are using an interactive (e.g., login) shell > > with SSH, and Capistrano is not. Believe me, I've explored and explored > > this, trying to find ways to make Capistrano friendly to non-posix > > shells, and "sh -c ..." is the closest I got. > > > > - Jamis > > > > On 5/19/09 2:25 PM, Scott Johnson wrote: > > > > > 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 -~----------~----~----~----~------~----~------~--~---
