I agree that's annoying, and I wouldn't be opposed to removing the
assumption that stderr == error. Feel free to put a patch together and
I'll consider it.
- Jamis
On Jun 12, 2008, at 10:07 AM, Jeff Forcier wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
