I apologize for that. This issue you're encountering is caused by the "fix" for the problem where doing sudo("foo && bar") would execute foo via sudo, but not bar.

You can try doing this:

  default_run_options[:shell] = false

But I'm sure that'll have other issues, too. (I suspect deploy:setup will have a good chance of not working correctly if you run without wrapping the command in a shell.)

Otherwise, you can try running without sudo:

  set :use_sudo, false

But again, that may break things, too, especially if your environment requires the use of sudo. At this point, I don't know how to fix both of these issues--have sudo work when the sudoer is restricted to a specific command-set, AND allow things like sudo("foo && bar") to work as expected. If anyone has any suggestions, I'd love to hear them.

- Jamis

On May 15, 2008, at 6:09 PM, Wes Gamble wrote:


All,

I recently ran my first deployment with cap 2.3 and noticed that my
custom sudo commands failed because there were being executed by
spawning a new shell and passing the command string to it, like so:

/bin/sh -c '<command string from my deploy file>'

I was able to resolve this by modifying my /etc/sudoers file and putting
"/bin/sh -c" in front of the command.  But is there a way to suppress
the spawning of a new shell so that it works the way it did in 2.2?

Thanks,
Wes

--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to