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.
Scott,
Fork capistrano-capistrano and send me a pull request, you can find me on
github as `leehambley`.
- Lee
2009/5/19 Scott Johnson sc...@scottjohnson.org
I have a couple of patches to perforce.rb to fix the 'cap
deploy:pending' task, which is pretty horribly broken in Capistrano
2.5.5
I have rather recently given up web development with Filemaker XSLT
and instead started to learn RoR. So far I love it, with the clear
exeption of deployment on Leopard server.
When I run cap deploy from my client I get Permission denied:
executing svn export -q --username admin --password
Jonas,
Either your server, or your workstation isn't allowed to access the SCM
server.
Please post your config file (deploy.rb) to pastie, or gist, and I'll advise
you what to try once I have that.
- Lee
2009/5/19 jo...@ibiz.se jo...@ibiz.se
I have rather recently given up web development
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
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
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
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
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
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
Scott,
Jamis hit the nail on the head with the escaping, you may still need to
`echo` in your backticks though, I doubt it (I use `hostname`) in one of
mine -- her'es something that works for me though:
http://gist.github.com/114257
Also, you can try this out, and take capistrano out of the
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
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
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
I have a server at Rimuhost that I would like to use Capistrano to
deploy a rails app to. Does anyone have an example of a working deploy
script that works with them?
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to
mksys,
What is special or significant about Rimuhost, I'm not familiar with them?
- Lee
2009/5/19 mksys m...@grandprix.com
I have a server at Rimuhost that I would like to use Capistrano to
deploy a rails app to. Does anyone have an example of a working deploy
script that works with them?
Scott,
Thanks - I'll pick those up.
- Lee
2009/5/19 Scott Johnson sc...@scottjohnson.org
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
Probably nothing, but as I am having trouble getting it to all to
work, I thought someone might have a good example as a starting point
to go from...
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to
capistrano-unsubscr...@googlegroups.com
For
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
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
I will try that and get back to you...
The root problem here is that the SSH exec request parses the supplied
command using the user's default shell, which is uncontrollable. Is
that right?
What if we did SSH exec of sh (without -c), then sent the command
over the channel (followed by exit)?
On 5/19/09 9:03 PM, Scott Johnson wrote:
I will try that and get back to you...
The root problem here is that the SSH exec request parses the supplied
command using the user's default shell, which is uncontrollable. Is
that right?
Right.
What if we did SSH exec of sh (without -c), then
This seems to work -- but I'm not sure I understand the full effects
of this change.
I changed command.rb line 213 to use single instead of double quotes:
cmd = '#{cmd}'
But what about the gsub in line 212 that's quoting $ and double
quotes? I assume with single quotes now we don't need to
I agree 100%. But unfortunately neither of those options is good for
me; the backticks are in the built-in deployment recipes (specifically
deploy:rollback:cleanup and the Perforce p4client_root). And my
default shell is tcsh because of an organization-wide, IT-
maintained .cshrc file which I
On 5/19/09 9:48 PM, Scott Johnson wrote:
I agree 100%. But unfortunately neither of those options is good for
me; the backticks are in the built-in deployment recipes (specifically
deploy:rollback:cleanup and the Perforce p4client_root). And my
default shell is tcsh because of an
I changed the 12 failing tests to expect single quotes and everything
seems to be working now. I tried both 'deploy' and 'deploy:rollback'
in my Rails app, with both tcsh and sh as the remote user's default
shell.
I pushed the change to scottj97/capistrano. Lee, I will send a pull
request.
26 matches
Mail list logo
