Question:

If I have a pty or tty master/slave pair, what can I not do with it if I only have the slave node's file descriptor? Or, put another way: what can I only do if I have the master node's file descriptor?

My Current Understanding:

I grok the "typical" relationship of a terminal/console/SSH having the master end for interfacing with a human, and one or more program (e.g. a shell and its children processes) being on the slave end. And I (loosely) grok the more unusual(/archaic?) usecases like using a TTY for other kinds of data links, like PPP. This question is not a "I don't get this TTY business" question. I'm asking about the ("low-level"?) "API" stuff: e.g. is there any termios/ioctl manipulations or other programmatic changes to the TTY pair that cannot be accomplished if you don't have access to the master FD?

I guess the obvious ones are:

• I can only read/write from the master end if I have the master end's FD.
• grantpt/unlockpt/ptsname can only be used on the master end's FD.

Anything else?

I've been on/off reading some man pages and experimenting on my Linux machines: the basic stuff one would want to do with a pty (e.g. stty columns 78, etc) seems to work on "either end". But I would suspect there's stuff only a process holding a file descriptor of the master end can do (especially because the master-slave name dichotomy suggests some unilateral control/dominion). And of course since I'm only testing on Linux, there's possible behavior differences between various versions/configurations of Linux and vs. the Unixes, so I don't want to assume that what I'm seeing is portable.

Motivation

(In case someone wants to know why I want to know)

1. General knowledge/curiosity.
2. I'm not in love with the current selection of command line tools for working with ptys. Without getting into the details, I've looked at reptyr, ptyget, expect/empty, screen/tmux(/neercs? the one with reptyr-like feature), dtach/abduco, and none of them hit my sweetspot of minimalist versatility. I'm trying to become more informed so I can better evaluate existing solutions and/or better design my own tool(s) to scratch my particular itch.

Thanks to StackOverflow's related-questions suggestions and other online searching since asking this, I've found a (partial?) answer:

• Enabling or disabling packet mode on a PTY in Linux can only be done if you have the master FD [See TIOCPKT at this manpage]
• Getting the Session ID associated with a TTY in Linux can only be done if you have the master FD (unclear if this is expected/intended behavior) [See TIOCGSID at this manpage]
• Re-sizing the TTY is only portable from the master FD in practice (a terminal emulator might resize the TTY when it's resized, but an application with just the slave FD has no real certainty that the master size resizes accordingly, or that the terminal driver will even accept a resize from the slave end). [Source]
• There is a trick for telling if the slave end of a TTY is opened, that you can't do if you don't have the master FD. [Source]
• A poll(2) on the master FD can get POLLPRI events for state changes on the slave end (if the terminal is in "packet mode").

I'll try to keep coming back to edit this as I learn more.