Scott, One more thing for you to try: if you have some posix-specific syntax in the backticks, does it still work, even if you're using tcsh?
What I'm wondering is, if you have this command, run from within tcsh: sh -c "echo something `date`" Does that `date` command get run by the posix shell you're invoking? Or does it get run by the tcsh shell that you're invoking the posix shell from? This is important, because if it's tcsh evaluating the backticks, then this will break non-posix shells whenever posix-only syntax is used in the backticks. Likewise, if you specify a non-posix shell for the :shell option, expecting the backticks to be evaluated by that non-posix shell, do things break if the outer (possibly posix) shell evaluates the backticks instead? This is all the reason behind the escaping of the backticks. They were there so that the backticks were evaluated by the inner (e.g., posix) shell, rather than the outer (invoking, and possibly non-posix) shell. - Jamis On 5/19/09 4:45 PM, Lee Hambley wrote: > Scott, > > Thanks - I'll pick those up. > > - Lee > > 2009/5/19 Scott Johnson <[email protected] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[email protected]>> wrote: > > >>>>>>>>>> Try, > > >>>>>>>>>> task :foo, :hosts => "my.host.com <http://my.host.com>" do > > >>>>>>>>>> run "echo date is `cat /bin/date` so there" > > >>>>>>>>>> end > > >>>>>>>>>> 2009/5/19 Scott Johnson<[email protected] > <mailto:[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 > <http://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 <http://my.host.com>"] > > >>>>>>>>>>> [my.host.com <http://my.host.com>] executing > command > > >>>>>>>>>>> ** [out :: my.host.com <http://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 <http://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 -~----------~----~----~----~------~----~------~--~---
