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<jamis.b...@gmail.com> 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<jamis.b...@gmail.com> 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<lee.hamb...@gmail.com> 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<sc...@scottjohnson.org>
>>>>>>> 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<lee.hamb...@gmail.com> wrote:
>>>>>>>> Try,
>>>>>>>> task :foo, :hosts => "my.host.com" do
>>>>>>>> run "echo date is `cat /bin/date` so there"
>>>>>>>> end
>>>>>>>> 2009/5/19 Scott Johnson<sc...@scottjohnson.org>
>>>>>>>>> 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
capistrano-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
