Ah! I think I may have found a work-around. If you use single-quotes instead of double-quotes, the string isn't immediately interpolated, so:
sh -c 'echo I need some `help`' appears to work, even if the calling shell is tcsh. Can you verify? - Jamis On 5/19/09 7:27 PM, Scott Johnson wrote: > I see your point. After further experimentation, I find you're > correct. The backticked command is being run by tcsh before calling > sh. Bummer. I had a feeling it wouldn't be quite so easy. > > Back to the drawing board. Or the workaround I had before I decided to > dive in. :( > > I cannot seem to find, just playing around on the command line, a way > to force tcsh to pass in the backticks to the sh command. That is > lame. I'm probably missing something stupid. > > % echo "I want my \`backticks\` dammit" > I want my \ dammit > > grr... > > > On 19 May, 16:00, Jamis Buck<[email protected]> wrote: >> 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. >> ... >> >> read more ยป > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
