Hi folks,
Executive summary: normal cap tasks like sudo and run seem to happily
print, and otherwise ignore, stderr output, and will only stop
execution if a command has a nonzero return value. Unfortunately,
capture is currently set up to die if it sees *any* stderr at all,
which is inconsistent and sometimes annoying, and I'm wondering if
this should be changed (or at least what the "best" workaround is).
Details:
Trying to use cap for a task like the following:
size = capture "du -sm /home/#{username} | cut -f1", :via => :sudo
In the situation where it needs to prompt me for my password, things
fall down: I do get the password prompt, and I successfully enter my
password (i.e. it has the effect of opening up a new grace period) but
then capture dies like so (specific values omitted):
user [me] :
Domain : hostname
* executing `deluser'
User to delete : username
* executing "sudo -p 'sudo password: ' du -sm /home/username | cut -
f1"
servers: ["hostname"]
[hostname] executing command
Password:
error processing "du -sm /home/username | cut -f1": "\n"
shell returned 1
As far as I can tell, this is because that newline character is coming
out of the sudo password prompt output (which is sent to stderr
instead of stdout) and capture is seeing it and wigging out due to
this line:
http://github.com/jamis/capistrano/tree/master/lib/capistrano/configuration/actions/inspect.rb#L37
or due to whatever it is within invoke_command that sets the :err
symbol when it sees stderr (it's not clear to me how many times that
block runs for a single-server invocation; I'm a Ruby newb).
So, I'm curious whether it's best that this behavior stay intact, or
if it should be removed, or replaced with code that would patch it
into the behavior seen with normal commands (haven't identified where
that is yet). Basically, the design decision appeared to be "capture
should die if there is any stderr" and I respectfully disagree :)
In terms of workarounds, I could just put some sort of no-op "normal"
sudo command prior to this capture line (right now it's the first line
in the task) which would ensure the prompt works OK, or I could
manually patch my local copy of the Capistrano gem. Is there another
solution I'm missing?
Thanks, sorry for the verbosity,
Jeff F.
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
