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. ** Attachment added: "patch to restore regular stderr handling by obtaining ticket first" http://launchpadlibrarian.net/37529306/26_stderr_handling.patch -- libgksu fails to start many programs, fails with: assert g_str_has_prefix str != NULL https://bugs.launchpad.net/bugs/501559 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
