Opened 11 years ago

Closed 10 years ago

#158 closed defect (fixed)

responsibility for usepty option is in the wrong place

Reported by: exarkun Owned by: dustin
Priority: major Milestone: 0.7.10
Version: 0.7.6 Keywords:


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).

Change History (6)

comment:1 Changed 11 years ago by 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?

comment:2 Changed 11 years ago by 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. :)

comment:3 Changed 11 years ago by warner

  • Milestone changed from undecided to 0.7.8
  • Owner set to warner
  • Status changed from new to assigned

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

comment:4 Changed 10 years ago by dustin

  • Milestone changed from 0.8.0 to 0.7.10

usePTY issues need to be solved in 0.7.10.

comment:5 Changed 10 years ago by dustin

  • Owner changed from warner to dustin
  • Status changed from assigned to new

comment:6 Changed 10 years ago by dustin

  • Resolution set to fixed
  • Status changed from new to closed
commit 071564761f46ea7089bbd6301589eeb466c3ec31
Author: Dustin J. Mitchell <>
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
Note: See TracTickets for help on using tickets.