Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?)

[enh <enh@google.com>]

On Mon, Jul 27, 2020 at 1:52 PM enh <enh@google.com> wrote:

>
>
> On Mon, Jul 27, 2020 at 1:32 PM Michael Kerrisk (man-pages) <
> mtk.manpages@gmail.com> wrote:
>
>> [I'm just threading Elliot into this discussion, because he works on
>> Android
>> and has an interest in finding also better terminology here. <EOM>]
>>
>> On 7/6/20 11:13 AM, Michael Kerrisk (man-pages) wrote:
>> > Hello Zack.
>> >
>> > On 7/4/20 6:52 PM, Zack Weinberg wrote:
>> >> On Thu, Jul 2, 2020 at 4:58 PM Michael Kerrisk <mtk.manpages@gmail.com>
>> wrote:
>> >>>
>> >>>> That said I think this is not as important as other, similar, changes
>> >>>> we could make. For instance, the term "master" is used _along with_
>> >>>> "slave" in manual/terminal.texi, and I fully intend to rewrite that
>> >>>> chapter to eliminate that terminology as soon as I find the time.
>> >>>> Anyone want to beat me to it?
>> >>>
>> >>> No, but please include me in the discussions. It would be good if libc
>> >>> and man-pages could find common terminology.
>> >>>
>> >>> But I agree also with Joseph that the scope is wider and we should
>> >>> think about what terminology POSIX might (be convinced to) switch to.
>> >>>
>> >>> Unlike Florian, I'm not excessively attached to the need to settle on
>> >>> a name that starts with 's'. I think it might be too easy to get into
>> >>> knots trying to find names that match 'm' and 's', and one should at
>> >>> least allow for the possibility of good names that don't fit with
>> >>> those letters; what would be best, IMO, is names that "feel right".
>> >>
>> >> I agree.  In particular I think there is no reason to struggle with
>> >> coming up with terms that fit "ptmx" and "pts" because BSD ptys use
>> >> totally different device node names anyway (tty[pqrs...]NN and
>> >> pty[pqrs...]NN) and there's no hope of finding something that works
>> >> with both.
>> >
>> > (Good point.)
>> >
>> >> I don't want to commit to terminology until I've had a go at rewriting
>> >> the manual, because I think doing the rewrite will be the easiest way
>> >> to figure out whether the new terms are good,
>> >
>> > I think that's a good text engineering approach. I think it's fine
>> > to cycle through a number of ideas, rejecting them until something feels
>> > "right".
>> >
>> >> but what I'm currently
>> >> thinking is:
>> >>
>> >>     "pty master device" -> "pty line-side device" or "outside device"
>> >>     "pty slave device"  -> "pty host-side device" or "inside device"
>> >>     /dev/ptmx stands for "pseudoterminal multiplexer"
>> >>     /dev/pts  stand for "pseudoterminals (directory of)"
>>
>
> fwiw, until the topic came up recently, i'd believed since the 1990s that
> that's /dev/ptmx and /dev/pts stood for anyway: multiplexer and a plural.
>
>
>> >> Currently I like "line-side" and "host-side" because it seems like a
>> >> natural generalization from true terminal device nodes (which are
>> >> always host-side) to pseudoterminals (additionally have a line-side
>> >> device node).  And it can generalize to the relationship between
>> >> Linux's /dev/ttyNN and /dev/vcs(a)NN as well.
>> >
>> > So far, "line-side" and "host-side" don't do it for me. But maybe
>> > I just need time to sit with those terms to get used to them.
>
>
> yeah, i'm can't say i'm particularly excited about those terms ... but
> "master" and "slave" weren't super obvious either.
>
> tbh, i don't think any of the choices in this thread are actually _worse_
> in terms of clarity (though existing practice was at least consistent so
> you could rtfm).
>
> i found the python reference i failed to find for michael earlier... it
> looks like i couldn't find it because it's the one master/slave change to
> python that they didn't actually submit. in
> https://github.com/python/cpython/pull/9100 they were going to go with
> parent and child but gvanrossum said they shouldn't change unless Unix
> changes.
>
> at least parent/child are names that most folks (including non-native
> speakers) will have had to learn already.
>
> golang went with pty/tty (
> https://github.com/creack/pty/commit/7dc38fb350b1d71383eed149e73acb7bae231ddb)
> which is interestingly simple.
>
>
>>
>>
> > As we consider names, I think it's good to keep in mind the rather
>> > diverse set of applications where pseudoterminals are used, including
>> >
>> > ssh etc.
>>
>
> there was some trolling about the commit on the openbsd mailing list which
> is why i've seen it, but afaict they've only renamed blacklist/whitelist so
> far.
>

actually, being a little less lazy and actually looking at the source, i
see openssh was already using pty and tty, which is what golang has
switched to.

if it wasn't for my desire to match the man page, i'd be sold on pty/tty at
this point --- direct, inoffensive, and no new words for non-native
speakers to learn :-)


> > xterm etc.
>> > expect
>> > tmux
>> > script
>> > unbuffer
>> >
>> > I just throw out some ideas (in the order master, slave):
>> >
>> > "driver" device plus "terminal" device
>> > "driver" device plus "client" device
>> > "proxy" device plus "terminal" device
>> > "proxy" device plus "client" device
>> >
>> > I'm not arguing that these are better than your terms. (At least,
>> > not yet ;-).) But I think it's useful to throw a lot of ideas into
>> > the mix, in the hope of sparking further ideas from others.
>> >
>> > Cheers,
>> >
>> > Michael
>> >
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Linux/UNIX System Programming Training: http://man7.org/training/
>>
>