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 -~----------~----~----~----~------~----~------~--~---
