make pty.fork() allocate a controlling tty

[raynorj]

BPO	838546
Nosy	@loewis
Files	pty_patch: patch to pty.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-11-09.11:12:00.000>
created_at = <Date 2003-11-08.20:21:59.000>
labels = ['library']
title = 'make pty.fork() allocate a controlling tty'
updated_at = <Date 2006-11-09.11:12:00.000>
user = 'https://bugs.python.org/raynorj'

bugs.python.org fields:

activity = <Date 2006-11-09.11:12:00.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2003-11-08.20:21:59.000>
creator = 'raynorj'
dependencies = []
files = ['5675']
hgrepos = []
issue_num = 838546
keywords = ['patch']
message_count = 4.0
messages = ['44861', '44862', '44863', '44864']
nosy_count = 2.0
nosy_names = ['loewis', 'raynorj']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue838546'
versions = ['Python 2.3']

[raynorj]

pty.fork() does not allocate a controlling tty on
systems that don't have os.forkpty(). The code for
pty.fork() tries to use os.forkpty(), and if it isn't
available, then it tries to do its work in python, but
it doesn't work.

The code does setup stdin, stdout, and stderr to use
the slave device, but it needs to do an explicit open
on the slave device to make it become a controlling tty.

This patch is against pty.py from python 2.3, but the
same change can be made to pty.py from python 2.2 and
it works there.

[loewis]

Logged In: YES
user_id=21627

What systems did you test this on? I remember ttyname
returning funny things on some systems.

[raynorj]

Logged In: YES
user_id=904832

This works on aix 5.2, 5.1, and 4.3.3. It also works on
hpux 10.20.

[loewis]

Logged In: YES
user_id=21627

I just looked at the source of the GNU C library, and it
essentially does the same thing:
in login_tty(), it does check whether ttyname returned a
non-NULL string, and then just
opens the terminal once. It might do the null check for a
different reason; it's not
certain that the fd really is a terminal.

On systems that support TIOCSCTTY, glibc uses that instead.

So thanks for the patch; I committed it as r52686 and
r52687. There might be room for
improvement, but that can come as a separate contribution.