responsibility for usepty option is in the wrong place

[exarkun]

usepty is an argument to buildbot create-slave. The correct place to configure this is on a per-step basis though (perhaps at the ShellCommand level, but maybe there's a better "thing which runs a child process" central location).

[warner]

The usepty argument was originally added to deal with platform differences (specifically solaris vs everything else). If I remember correctly, the main issue was that usepty=True on solaris is what let you kill off a process and all of its descendants at once (using os.kill(-pid) or something). This makes 'stop build' work much better, but didn't seem to work on all platforms.

What sort of situation would make you want to have usepty=True for one step and then usepty=False for a different one? And would you be comfortable specifying it for the buildstep but *not* for the platform?

[exarkun]

A buildstep I am currently using runs a program which changes the format of its output based on whether stdout is a PTY or not. If the option is set the wrong way, I won't be able to parse the output (I'm not actually parsing it yet, and I may decide never to parse it, since it'll be hard either way - but the pty version of the output also looks like garbage in the output log file published by buildbot).

Of course, now that I think about it, I can fake usePTY=False in the buildstep by making the command "realcommand | cat" or some variation. Of course it'd be nice if I could spell this without a hack. :)

[warner]

Yeah, we need this. See the comments in #198.

[dustin]

usePTY issues need to be solved in 0.7.10.

[dustin]

commit 071564761f46ea7089bbd6301589eeb466c3ec31
Author: Dustin J. Mitchell <dustin@zmanda.com>
Date:   Sun Feb 22 13:23:53 2009 -0500

    (refs #158) make usePTY a step parameter; change default to no
    
    The default for --usepty becomes 0 (no), and by default, ShellCommands
    obey that setting.  Shell commands run from Source subclasses set this
    to False, as it's seldom necessary to use a PTY for these commands.
    
    Add a new command_version, 2.7, indicating slave support for this flag