Comment 4 for bug 501559

ok, unless I'm missing something, the dichotomy comes about this way:

WITH the forkpty option ->

try to do a sudo -v to obtain ticket, only read a small amount of stderr
if sudo -v succeeds, then do a g_spawn_async of the actual command (since we've obtained a ticket, this doesn't ask for the password)

WITHOUT forkpty ->

try to fork/exec the command directly, only read a small amount of stderr to handle sudo problems, any other stderr output results in EPIPE

According to a bug that mvo pointed me to, the impetus for dropping forkpty was that changing the pty buggered up some sudo options. However, I'm assuming the first method of getting the ticket first was OK.

That being said, this patch implements the same program flow under the pipe version, as the forkpty version.