Pseudoterminal terminology in POSIX

Pseudoterminal terminology in POSIX

[Michael Kerrisk]

Elliot Hughes and I both noticed a point from "Minutes of the 3rd August 2020
Teleconference":

[[
On Tue, Aug 4, 2020 at 5:52 PM Andrew Josey <ajosey@opengroup.org> wrote:
>
> All
> Enclosed are the minutes of yesterdays teleconference
> regards
> Andrew

[...]

> * General news
>
> We discussed terminology usage, in particuler terms such as
> master/slave, blacklist/whitelist.  It was agreed some terminology
> for pseudo-terminals could be better described using more functionally
> descriptive terms, but the details of this are left to a future bug
> report.  Andrew and Geoff took an action to investigate further
> and come back with an analysis.
]]

I see that Elliot already replied to the Minutes with some thoughts
about this. I had already been working on thismail on the topic, which
reiterates some details that Elliot gave, but also adds some
information, and brings a lot of relevant people into CC. (I've
already notified those people that only subscribers can post to the
Austin list, and presumably those not already subscribed will
subscribe if they want to add to the discussion.)

The master-slave terminology with respect to pseudoterminals has
recently been under active discussion in the GNU C library and Linux
man-pages mailing lists (see [1]). Currently, we are considering at
least one possible proposal for a language change, but there may yet
be others. In any case, I and others thought it would be a wise idea
to involve TOG in this discussion, so that, ideally, we could come up
with a shared standard for replacement terminology.

The proposal that has seen some discussion, and met with some positive
feedback, is [2]. The concept was proposed by Elliot, inspired by a
similar change that was made in relevant golang libraries; I've
written an implementation of the idea (i.e., a proposed patch) for the
Linux manual pages (again, see [2]).

The essence of the idea is simple. Let's not invent completely new
terms, but rather rework existing (familiar) terminology a little, as
follows:

    pseudoterminal (device) ==> "pseudoterminal device pair"

   slave ==> "terminal device"
           (or "terminal end of the pseudoterminal device pair")

    master ==> "pseudoterminal device"
           (or "pseudoterminal end of the pseudoterminal device pair")

The resulting language (as it appears in the proposed changes for the
Linux manual pages) is reasonably clear, albeit a little clunky in
places (wordings like "the (pseudo)terminal end of the pseudoterminal
device pair" are clear, but a little verbose).

Aside from the obvious points (raising a bug on the Austin bug
tracker, and proposing line edits to the standard), is there anything
else that we can do to help along the process of changing the
terminology in POSIX? Also, any feedback on the proposal in [2] would be
welcome.

With best regards,

Michael Kerrisk

[1] https://sourceware.org/pipermail/libc-alpha/2020-July/115792.html

[2] https://lore.kernel.org/linux-man/b3b4cf95-5eaa-0b4e-34cc-1a855e7148b6@gmail.com/

Re: Pseudoterminal terminology in POSIX

[Steffen Nurpmeso]

Michael Kerrisk via austin-group-l at The Open Group wrote in
 <CALxWeYrisuzEPVEHOQSFJ8G_=8-VTAOTNBquyszOZMid7YfT=Q@mail.gmail.com>:
 |Elliot Hughes and I both noticed a point from "Minutes of the 3rd August \
 |2020
 |Teleconference":
 ..
 |On Tue, Aug 4, 2020 at 5:52 PM Andrew Josey <ajosey@opengroup.org> wrote:
 ...
 |> * General news
 |>
 |> We discussed terminology usage, in particuler terms such as
 |> master/slave, blacklist/whitelist.  It was agreed some terminology
 |> for pseudo-terminals could be better described using more functionally
 |> descriptive terms, but the details of this are left to a future bug
 |> report.  Andrew and Geoff took an action to investigate further
 |> and come back with an analysis.
 ...
 |The essence of the idea is simple. Let's not invent completely new
 |terms, but rather rework existing (familiar) terminology a little, as
 |follows:
 |
 |    pseudoterminal (device) ==> "pseudoterminal device pair"
 |
 |   slave ==> "terminal device"
 |           (or "terminal end of the pseudoterminal device pair")
 |
 |    master ==> "pseudoterminal device"
 |           (or "pseudoterminal end of the pseudoterminal device pair")

How about ancillary or accessory terminal device for the slave.
Having said that love is on its way out, rather than in, and
cosmetics on the language side do not do anything against the
dramatical and increasing hardening of the actual facts.  Likely
quite the opposite.  That is just my point of view, of course.

 |The resulting language (as it appears in the proposed changes for the
 |Linux manual pages) is reasonably clear, albeit a little clunky in
 |places (wordings like "the (pseudo)terminal end of the pseudoterminal
 |device pair" are clear, but a little verbose).

Yes.  It is terrible and absolutely unclear (to me).  And
presumely i would become dazed if i would read an entire manual
with the above terms.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Pseudoterminal terminology in POSIX

[Michael Kerrisk (man-pages)]

[Restoring the CC, which seems to have got lost along the way; it's best if
we keep it, since some people who are involved on the Linux/Glibc side may 
not be on the Austin list.]

Hello Geoff and Steffen,

Thanks for your feedback.

On 8/5/20 4:20 PM, Geoff Clare via austin-group-l at The Open Group wrote:
> Steffen Nurpmeso wrote, on 05 Aug 2020:
>>
>> Michael Kerrisk via austin-group-l at The Open Group wrote in
>>  <CALxWeYrisuzEPVEHOQSFJ8G_=8-VTAOTNBquyszOZMid7YfT=Q@mail.gmail.com>:
>>  |Elliot Hughes and I both noticed a point from "Minutes of the 3rd August \
>>  |2020
>>  |Teleconference":
>>  ..
>>  |On Tue, Aug 4, 2020 at 5:52 PM Andrew Josey <ajosey@opengroup.org> wrote:
>>  ...
>>  |> * General news
>>  |>
>>  |> We discussed terminology usage, in particuler terms such as
>>  |> master/slave, blacklist/whitelist.  It was agreed some terminology
>>  |> for pseudo-terminals could be better described using more functionally
>>  |> descriptive terms, but the details of this are left to a future bug
>>  |> report.  Andrew and Geoff took an action to investigate further
>>  |> and come back with an analysis.
>>  ...
>>  |The essence of the idea is simple. Let's not invent completely new
>>  |terms, but rather rework existing (familiar) terminology a little, as
>>  |follows:
>>  |
>>  |    pseudoterminal (device) ==> "pseudoterminal device pair"
> 
> I'm okay with that, but ...
> 
>>  |
>>  |   slave ==> "terminal device"
> 
> many other things are also terminal devices, so this doesn't work unless ...
> 
>>  |           (or "terminal end of the pseudoterminal device pair")
> 
> you use this cumbersome phrasing every time you refer to it.

(I don't really agree; context is everything; see below.)

>>  |
>>  |    master ==> "pseudoterminal device"
>>  |           (or "pseudoterminal end of the pseudoterminal device pair")
> 
> This makes no sense to me.  Given the phrase "pseudoterminal device pair",
> I would naturally expect "pseudoterminal device" could be used to refer
> to either of the individual devices in the pair, rather than one and not
> the other.

So, I think Elliot's mail provided a good response to this.
I am probably overcompensating with my language. In practice,
it may well be that people settle into the terminology

pseudoterminal device pair
pseudoterminal
terminal

And, in the context, and with familiarity, the last two terms
will be understood to mean the respective end points, so that we
would just talk about "the pseudoterminal and the terminal
that compose the device pair". And the fact that many things are
terminals doesn't really undermine this; the context would make it
clear, I think.

>> How about ancillary or accessory terminal device for the slave.
> 
> I think ancillary would actually be more applicable to the master.
> 
>>
>>  |The resulting language (as it appears in the proposed changes for the
>>  |Linux manual pages) is reasonably clear, albeit a little clunky in
>>  |places (wordings like "the (pseudo)terminal end of the pseudoterminal
>>  |device pair" are clear, but a little verbose).
>>
>> Yes.  It is terrible and absolutely unclear (to me).  And
>> presumely i would become dazed if i would read an entire manual
>> with the above terms.
> 
> I agree, it's too cumbersome.
> 
> My own thoughts up to now had been that, since the slave side is the
> side that is intended to be used as a terminal in the normal way, the
> slave should be called the "primary" device.  I hadn't come up with a
> word for the master side, but Steffen's suggestion of "ancillary" works
> quite well (I just saw a dictionary definition that said "providing
> necessary support to the primary ...").

Notwithstanding my arguments above, I'm not fixed in the terminology
that Elliot and I are suggesting, and I would not have a problem with
the terms "primary" and "ancillary" (and your [Geoff] suggested 
association of "ancillary" with the "master" seems more natural 
than associating it with the "slave").

The point is that if we come up with some terminology that is not
hideous, people will adapt. I remain somewhat agnostic about
what the terminology should be.

Cheers,

Michael

Re: Pseudoterminal terminology in POSIX

[Michael Kerrisk (man-pages)]

[again restoring the CC]

On 8/5/20 5:28 PM, Paul Smith via austin-group-l at The Open Group wrote:
> On Wed, 2020-08-05 at 08:00 -0700, Donn Terry via austin-group-l at The
> Open Group wrote:
>> The suggestions here so far are cumbersome and tend to be ambiguous. 
>> The old m-word and sl-word, and also "client" and "server" could
>> potentially be interpreted backwards from the conventional intent.
>> (You can think about it as the sl-word/client actually being in
>> control: telling the m-word/server what it's supposed to be doing,
>> e.g. "execute this command line".)  
>>
>> How about "provider" and "consumer"? "Pseudoterminal provider" and
>> "...consumer" seem (at least to me) to be unambiguous in terms of the
>> reversal above, (reasonably) clear in meaning, and politically
>> neutral. Have the other discussions not shown here considered this?
> 
> To me even "provider" / "consumer" still has this issue: do you
> consider the pseudoterminal as providing to the terminal, or the
> terminal as providing to the pseudoterminal.  Both seem legitimate
> enough interpretations to create confusion.

That was my immediate thought also, unfortunately. That said,
again, I think if we settle on a terminology (even provider/consumer),
people will adapt. (But, i still prefer pseudoterminal/terminal or
ancillary/primary).

> To remove ambiguity perhaps we need to think about the attributes that
> are unique to each element of the pair and use that in the term, for
> example "backend" / "frontend".
> 
> This would have to be introduced, something like "a pseudoterminal
> device pair consists of a backend terminal device and a frontend
> pseudoterminal device".

Yes. The terminology, whatever it is, needs to be introduced and 
defined. That alone will remove a lot of ambiguity, regardless of
the terms that are settled on.

Thanks,

Michael

Re: Pseudoterminal terminology in POSIX

[Larry Dwyer]

How about the "control" side and the "terminal" side (of the paired 
device files)?

Cheers,
Larry

On 8/5/2020 4:21 AM, Michael Kerrisk via austin-group-l at The Open 
Group wrote:
> Elliot Hughes and I both noticed a point from "Minutes of the 3rd August 2020
> Teleconference":
> 
> [[
> On Tue, Aug 4, 2020 at 5:52 PM Andrew Josey <ajosey@opengroup.org> wrote:
>>
>> All
>> Enclosed are the minutes of yesterdays teleconference
>> regards
>> Andrew
> 
> [...]
> 
>> * General news
>>
>> We discussed terminology usage, in particuler terms such as
>> master/slave, blacklist/whitelist.  It was agreed some terminology
>> for pseudo-terminals could be better described using more functionally
>> descriptive terms, but the details of this are left to a future bug
>> report.  Andrew and Geoff took an action to investigate further
>> and come back with an analysis.
> ]]
> 
> I see that Elliot already replied to the Minutes with some thoughts
> about this. I had already been working on thismail on the topic, which
> reiterates some details that Elliot gave, but also adds some
> information, and brings a lot of relevant people into CC. (I've
> already notified those people that only subscribers can post to the
> Austin list, and presumably those not already subscribed will
> subscribe if they want to add to the discussion.)
> 
> The master-slave terminology with respect to pseudoterminals has
> recently been under active discussion in the GNU C library and Linux
> man-pages mailing lists (see [1]). Currently, we are considering at
> least one possible proposal for a language change, but there may yet
> be others. In any case, I and others thought it would be a wise idea
> to involve TOG in this discussion, so that, ideally, we could come up
> with a shared standard for replacement terminology.
> 
> The proposal that has seen some discussion, and met with some positive
> feedback, is [2]. The concept was proposed by Elliot, inspired by a
> similar change that was made in relevant golang libraries; I've
> written an implementation of the idea (i.e., a proposed patch) for the
> Linux manual pages (again, see [2]).
> 
> The essence of the idea is simple. Let's not invent completely new
> terms, but rather rework existing (familiar) terminology a little, as
> follows:
> 
>      pseudoterminal (device) ==> "pseudoterminal device pair"
> 
>     slave ==> "terminal device"
>             (or "terminal end of the pseudoterminal device pair")
> 
>      master ==> "pseudoterminal device"
>             (or "pseudoterminal end of the pseudoterminal device pair")
> 
> The resulting language (as it appears in the proposed changes for the
> Linux manual pages) is reasonably clear, albeit a little clunky in
> places (wordings like "the (pseudo)terminal end of the pseudoterminal
> device pair" are clear, but a little verbose).
> 
> Aside from the obvious points (raising a bug on the Austin bug
> tracker, and proposing line edits to the standard), is there anything
> else that we can do to help along the process of changing the
> terminology in POSIX? Also, any feedback on the proposal in [2] would be
> welcome.
> 
> With best regards,
> 
> Michael Kerrisk
> 
> [1] https://sourceware.org/pipermail/libc-alpha/2020-July/115792.html
> 
> [2] https://lore.kernel.org/linux-man/b3b4cf95-5eaa-0b4e-34cc-1a855e7148b6@gmail.com/
> 
> 

Re: Pseudoterminal terminology in POSIX

[Joerg Schilling]

Larry Dwyer via austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:

> How about the "control" side and the "terminal" side (of the paired 
> device files)?

The Solaris man pty page since a really long time has this:

    By default, 48 pseudo-terminal pairs are configured as  follows:

       /dev/pty[p-r][0-9a-f] controller devices
       /dev/tty[p-r][0-9a-f] slave devices

so I would be OK with "controller" side and "terminal" side.


Jörg

-- 
 EMail:joerg@schily.net                    (home) Jörg Schilling D-13353 Berlin
    joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

Re: Pseudoterminal terminology in POSIX

[Thor Lancelot Simon]

On Sat, Aug 08, 2020 at 04:18:10PM -0700, Larry Dwyer via austin-group-l at The Open Group wrote:
> How about the "control" side and the "terminal" side (of the paired device
> files)?

How about the "pty side" and the "tty side"?  It seems hard to be more
neutral than that and we can be sure there is no ambiguity.

Thor

Re: Pseudoterminal terminology in POSIX

[Zack Weinberg]

On Mon, Aug 10, 2020 at 9:21 AM Joerg Schilling
<Joerg.Schilling@fokus.fraunhofer.de> wrote:
> Larry Dwyer via austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:
>
> > How about the "control" side and the "terminal" side (of the paired
> > device files)?
>
> The Solaris man pty page since a really long time has this:
>
>     By default, 48 pseudo-terminal pairs are configured as  follows:
>
>        /dev/pty[p-r][0-9a-f] controller devices
>        /dev/tty[p-r][0-9a-f] slave devices
>
> so I would be OK with "controller" side and "terminal" side.

(libc-alpha, Michael - sorry about not responding to any of this
thread last week, my actual job has had me swamped.  I still mean to
give a whack at revising the glibc manual with this terminology but I
won't be able to get to it until *next* week at the earliest.)

I like "terminal side" for the tty[p-r][0-9a-f] | pts/[0-9]+ devices,
but "control(ler) side" still gives the wrong impression IMNSHO.  The
pty[p-r][0-9a-f] | ptmx devices don't exert any actual control over
anything.  They are just the other side of a bidirectional
communication channel.  It's not like USB, where the "master" side is
the only one that can initiate a data transfer.

The relationship between "real" terminals and "pseudo" terminals is
very much like the relationship between remote network sockets and
loopback sockets.  Data received from, or written to, a "real"
terminal is transferred over a hardware communications channel from/to
an external device, such as an RS232 serial line or a
directly-attached console.  With a "pseudo" terminal, on the other
hand, the data is transferred over a software queue from/to another
program running on the same computer (e.g. sshd, screen, xterm).  So I
think an inside/outside metaphor is more appropriate: how about
"outside", "exterior", or "external" device for the pty[p-r][0-9a-f] |
ptmx devices ?

zw

Re: Pseudoterminal terminology in POSIX

[Samuel Thibault]

Hello,

Zack Weinberg, le lun. 10 août 2020 14:10:42 -0400, a ecrit:
> "control(ler) side" still gives the wrong impression IMNSHO.  The
> pty[p-r][0-9a-f] | ptmx devices don't exert any actual control over
> anything.

? They do to some extent: writing ^C on that side will send a SIGINT to
the foreground process there (even if owned by another user!).

Samuel

Re: Pseudoterminal terminology in POSIX

[Samuel Thibault]

Samuel Thibault, le lun. 10 août 2020 20:17:53 +0200, a ecrit:
> Zack Weinberg, le lun. 10 août 2020 14:10:42 -0400, a ecrit:
> > "control(ler) side" still gives the wrong impression IMNSHO.  The
> > pty[p-r][0-9a-f] | ptmx devices don't exert any actual control over
> > anything.
> 
> ? They do to some extent: writing ^C on that side will send a SIGINT to
> the foreground process there (even if owned by another user!).

Unless they opened it with O_NOCTTY to avoid letting it be their
"controlling terminal". There really is some "control" terminology here,
which is initiated by the pty side.

Samuel

Re: Pseudoterminal terminology in POSIX

[Michael Kerrisk (man-pages)]

[repairing CC]


On 8/6/20 6:53 AM, Oğuz via austin-group-l at The Open Group wrote:
> 5 Ağustos 2020 Çarşamba tarihinde Michael Kerrisk (man-pages) <
> mtk.lists@gmail.com> yazdı:
> 
>> On 8/5/20 7:12 PM, Oğuz via austin-group-l at The Open Group wrote:
>>> 5 Ağustos 2020 Çarşamba tarihinde Robert Elz via austin-group-l at The
>> Open
>>> Group <austin-group-l@opengroup.org> yazdı:
>>>
>>>>     Date:        Wed, 05 Aug 2020 11:28:45 -0400
>>>>     From:        "Paul Smith via austin-group-l at The Open Group" <
>>>> austin-group-l@opengroup.org>
>>>>     Message-ID:  <1d8c5e6e96fbdd47ce143a566b57d
>> b2c803d4898.camel@gnu.org>
>>>>
>>>>   | do you consider the pseudoterminal as providing to the terminal, or
>> the
>>>>   | terminal as providing to the pseudoterminal.
>>>>
>>>> How did anyone ever get to a question like that?  - there are a pair of
>>>> devices which between them implement a pseudo-terminal (which is just
>>>> like a terminal, to the application, but isn't one ... hence
>>>> pseudo-terminal).
>>>>
>>>> Personally I'm quite happy with the existing terminology, and see no
>>>> particular need for change (as close to meaningless as the terms are
>>>> in this context - they are well established, anything different will
>>>> just create confusion).
>>>>
>>>>
>>> Couldn't agree more. I don't understand what problem such a change in the
>>> terminology is supposed to solve.
>>
>> The problems have already been widely discussed elsewhere. For a
>> summary, see, for example, https://lwn.net/Articles/823224/
>>
>>
> I see, but changing well established, concrete terms with barely related,
> abstract, far-fetched alternatives just to make a bunch of oversensitive
> snowflakes doesn't make any sense (to me, at least).

Thanks for clarifying your perspective.

> If this change is going to happen no matter what we say, at least add a
> glossary somewhere for us non-native speakers where we can look up what
> each nonsensical alternative term actually means, unless you want to
> exclude us too, of course.

Some kind of change is pretty much inevitable. There are of course
already glossaries, in the form of documentation, and the standard.
The question is simply how to update these.

Thanks,

Michael

Re: Pseudoterminal terminology in POSIX

[Michael Kerrisk (man-pages)]

On 8/10/20 3:58 PM, Thor Lancelot Simon wrote:
> On Sat, Aug 08, 2020 at 04:18:10PM -0700, Larry Dwyer via austin-group-l at The Open Group wrote:
>> How about the "control" side and the "terminal" side (of the paired device
>> files)?
> 
> How about the "pty side" and the "tty side"?  It seems hard to be more
> neutral than that and we can be sure there is no ambiguity.

This is an option that came up in the glibc/Linux man-pages discussion.
My objection is that I want proper nouns that one can use in a prose
description of pseudoterminals.

Thanks,

Michael

Re: Pseudoterminal terminology in POSIX

[Michael Kerrisk (man-pages)]

On 8/9/20 1:18 AM, Larry Dwyer via Libc-alpha wrote:
> How about the "control" side and the "terminal" side (of the paired 
> device files)?

Thanks for the suggestion. As far as I'm concerned, that would 
also be an option worth considering.

Thanks,

Michael

Re: Pseudoterminal terminology in POSIX

[Michael Kerrisk (man-pages)]

Hi Zack,

On 8/10/20 8:10 PM, Zack Weinberg wrote:
> On Mon, Aug 10, 2020 at 9:21 AM Joerg Schilling
> <Joerg.Schilling@fokus.fraunhofer.de> wrote:
>> Larry Dwyer via austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:
>>
>>> How about the "control" side and the "terminal" side (of the paired
>>> device files)?
>>
>> The Solaris man pty page since a really long time has this:
>>
>>     By default, 48 pseudo-terminal pairs are configured as  follows:
>>
>>        /dev/pty[p-r][0-9a-f] controller devices
>>        /dev/tty[p-r][0-9a-f] slave devices
>>
>> so I would be OK with "controller" side and "terminal" side.
> 
> (libc-alpha, Michael - sorry about not responding to any of this
> thread last week, my actual job has had me swamped.  I still mean to
> give a whack at revising the glibc manual with this terminology but I
> won't be able to get to it until *next* week at the earliest.)
> 
> I like "terminal side" for the tty[p-r][0-9a-f] | pts/[0-9]+ devices,
> but "control(ler) side" still gives the wrong impression IMNSHO.  The
> pty[p-r][0-9a-f] | ptmx devices don't exert any actual control over
> anything.  They are just the other side of a bidirectional
> communication channel.  It's not like USB, where the "master" side is
> the only one that can initiate a data transfer.

Yes, but on the other hand, the program on the master side is often
providing a some kind of "driving" functionality to operate the
program on the salve slide. So the term "control" here doesn't seem
completely out of place. And Joerg's observation that "controller"
is existing terminology in at least one implementation is an 
interesting data point.

> The relationship between "real" terminals and "pseudo" terminals is
> very much like the relationship between remote network sockets and
> loopback sockets.

Well, maybe, but...

> Data received from, or written to, a "real"
> terminal is transferred over a hardware communications channel from/to
> an external device, such as an RS232 serial line or a
> directly-attached console.  With a "pseudo" terminal, on the other
> hand, the data is transferred over a software queue from/to another
> program running on the same computer (e.g. sshd, screen, xterm).  

... the analogy is not obvious (it was only clear to me after
you elaborated it).

> So I
> think an inside/outside metaphor is more appropriate: how about
> "outside", "exterior", or "external" device for the pty[p-r][0-9a-f] |
> ptmx devices ?

We can certainly add it to the list of candidates, but there
are others proposals that feel better to me.

I'll let the conversation run a bit longer, and then try to
summarize the list of proposals we have so far.

Thanks,

Michael

Re: Pseudoterminal terminology in POSIX

[Dirk Fieldhouse]

On 09/08/20 00:18, Larry Dwyer via austin-group-l at The Open Group wrote:
> How about the "control" side and the "terminal" side (of the paired
> device files)?
All good -- until abused partners ("coercive control") or people
imminently expected to die, and their supporters, start a clamour.

In fact I'll make sure only to cast my Algol68 types in future and never
coerce them, just in case. I'll absolutely never add an 'e' to 'cast'.

Leaving satire, if it was, aside, the problem with changing technical
terms is that all the previous valid uses remain, so you need a glossary
to explain that the new term replaces the old one, and thus
documentation into the foreseeable future has to mention the old term as
well. For instance, people who read the article that's the second G-hit
on "pty tty" for me at
<https://dev.to/napicella/linux-terminals-tty-pty-and-shell-192e> would
wonder what happened to the components described there.

If the change is to avoid perceived offence, the _mention_ of the old
term has to come with a disclaimer that it was a historical metaphor
applied to technology and should not be construed as a reference to its
original sense. Personally I would just say that instead and let the
term lie.

Or just re-spell, perhaps 'moster' (a place in Norway, strip-Jenga?) and
'slove' (a band, "did split"), since the original metaphor in this case
doesn't seem to help understanding. As these are meaningless to almost
everyone, they could stand for the originals in all the existing uses
and people not in the know could use their existing internal spelling
corrector, as with colour/color.

/df

--
London SW6
UK

Re: Pseudoterminal terminology in POSIX

[Thor Lancelot Simon]

On Tue, Aug 11, 2020 at 10:31:58AM +0200, Michael Kerrisk (man-pages) wrote:
> On 8/10/20 3:58 PM, Thor Lancelot Simon wrote:
> > On Sat, Aug 08, 2020 at 04:18:10PM -0700, Larry Dwyer via austin-group-l at The Open Group wrote:
> >> How about the "control" side and the "terminal" side (of the paired device
> >> files)?
> > 
> > How about the "pty side" and the "tty side"?  It seems hard to be more
> > neutral than that and we can be sure there is no ambiguity.
> 
> This is an option that came up in the glibc/Linux man-pages discussion.
> My objection is that I want proper nouns that one can use in a prose
> description of pseudoterminals.

All names are proper nouns.

They might not be the particular proper nouns that we're used to seeing,
but they are still proper nouns!

Thor

Re: Pseudoterminal terminology in POSIX

[Michael Kerrisk]

On Tue, Aug 11, 2020 at 1:51 PM Thor Lancelot Simon via austin-group-l
at The Open Group <austin-group-l@opengroup.org> wrote:
>
> On Tue, Aug 11, 2020 at 10:31:58AM +0200, Michael Kerrisk (man-pages) wrote:
> > On 8/10/20 3:58 PM, Thor Lancelot Simon wrote:
> > > On Sat, Aug 08, 2020 at 04:18:10PM -0700, Larry Dwyer via austin-group-l at The Open Group wrote:
> > >> How about the "control" side and the "terminal" side (of the paired device
> > >> files)?
> > >
> > > How about the "pty side" and the "tty side"?  It seems hard to be more
> > > neutral than that and we can be sure there is no ambiguity.
> >
> > This is an option that came up in the glibc/Linux man-pages discussion.
> > My objection is that I want proper nouns that one can use in a prose
> > description of pseudoterminals.
>
> All names are proper nouns.
>
> They might not be the particular proper nouns that we're used to seeing,
> but they are still proper nouns!

Let me clarify then: my preference is to have natural language nouns,
words that a speaker who was unfamiliar with the domain would know (or
could reasonably guess) how to pronounce when reading them.

Thanks,

Michael

Re: Pseudoterminal terminology in POSIX

[Joshua M. Clulow]

On Tue, 11 Aug 2020 at 01:33, Michael Kerrisk man-pages via
austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:
> On 8/9/20 1:18 AM, Larry Dwyer via Libc-alpha wrote:
> > How about the "control" side and the "terminal" side (of the paired
> > device files)?
>
> Thanks for the suggestion. As far as I'm concerned, that would
> also be an option worth considering.

I work on the illumos project and a few of us have been having a
(not yet public) discussion about this lately as well.  I think the
best one we could think of was:

    the "control" side for the result of posix_openpt()

    the "subordinate" side for the result of ptsname() and open(),
    "/dev/pts" still makes sense, etc

    we would rename our "/dev/ptmx" device file the "manager
    driver" rather than the "master"

We would strongly consider using the same shift as other projects,
but I think only if they actually make sense; e.g., the "terminal"
and "pseudoterminal" end doesn't really stand out as completely
clear.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org

Re: Pseudoterminal terminology in POSIX

[Steffen Nurpmeso]

Joshua M. Clulow via austin-group-l at The Open Group wrote in
 <CAEwA5nKtyJTnQEXZZaiHywTpfDCprmupnCiq9kf5oupV7iG8RA@mail.gmail.com>:
 |On Tue, 11 Aug 2020 at 01:33, Michael Kerrisk man-pages via
 |austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:
 |> On 8/9/20 1:18 AM, Larry Dwyer via Libc-alpha wrote:
 |>> How about the "control" side and the "terminal" side (of the paired
 |>> device files)?
 |>
 |> Thanks for the suggestion. As far as I'm concerned, that would
 |> also be an option worth considering.
 |
 |I work on the illumos project and a few of us have been having a
 |(not yet public) discussion about this lately as well.  I think the
 |best one we could think of was:
 |
 |    the "control" side for the result of posix_openpt()
 |
 |    the "subordinate" side for the result of ptsname() and open(),

You know, (In)Subordination has a very military touch, with
exclamation mark many may have heard it.  Also in traditional
(white western world) education as such.  Like in first the
pizzle, then the bull pizzle, maybe.  So to say.  In my ears this
sounds more aggressive and weird than slave, in a technical
combination of master/slave, ever could.
Also isn't it a bit submissive here; it is under control, but
other than that.

 |    "/dev/pts" still makes sense, etc
 |
 |    we would rename our "/dev/ptmx" device file the "manager
 |    driver" rather than the "master"
 |
 |We would strongly consider using the same shift as other projects,
 |but I think only if they actually make sense; e.g., the "terminal"
 |and "pseudoterminal" end doesn't really stand out as completely
 |clear.

Manager sounds strange here, i always liked manager/worker
terminologie for threads, and used them like that (and am the
opinion that .. but that is something different and has sailed),
but for a pseudo terminal?  I think that if the standard wants to
be future proof manager should be avoided.  These guys induce
strange, ruthless and devastating decisions which destroy life on
earth (as we used to know it), so i for one do not want to be
harassed by such a term.

In accordance, maybe,
Ciao from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: Pseudoterminal terminology in POSIX

[Thor Lancelot Simon]

On Tue, Aug 11, 2020 at 10:31:58AM +0200, Michael Kerrisk man-pages via austin-group-l at The Open Group wrote:
> On 8/10/20 3:58 PM, Thor Lancelot Simon wrote:
> > On Sat, Aug 08, 2020 at 04:18:10PM -0700, Larry Dwyer via austin-group-l at The Open Group wrote:
> >> How about the "control" side and the "terminal" side (of the paired device
> >> files)?
> > 
> > How about the "pty side" and the "tty side"?  It seems hard to be more
> > neutral than that and we can be sure there is no ambiguity.
> 
> This is an option that came up in the glibc/Linux man-pages discussion.
> My objection is that I want proper nouns that one can use in a prose
> description of pseudoterminals.

Perhaps "lead" and "follower"?  This terminology comes from multiple unit
control systems on railroad locomotives (where it's been used interchangably
with the problematic "master" / "slave" for a long time) and I think it's
fairly descriptive of the situation with the pty control and terminal
units, too.

Re: Pseudoterminal terminology in POSIX

[Dave Martin]

On Wed, Aug 12, 2020 at 03:19:00PM +0200, Steffen Nurpmeso wrote:
> Joshua M. Clulow via austin-group-l at The Open Group wrote in
>  <CAEwA5nKtyJTnQEXZZaiHywTpfDCprmupnCiq9kf5oupV7iG8RA@mail.gmail.com>:
>  |On Tue, 11 Aug 2020 at 01:33, Michael Kerrisk man-pages via
>  |austin-group-l at The Open Group <austin-group-l@opengroup.org> wrote:
>  |> On 8/9/20 1:18 AM, Larry Dwyer via Libc-alpha wrote:
>  |>> How about the "control" side and the "terminal" side (of the paired
>  |>> device files)?
>  |>
>  |> Thanks for the suggestion. As far as I'm concerned, that would
>  |> also be an option worth considering.
>  |
>  |I work on the illumos project and a few of us have been having a
>  |(not yet public) discussion about this lately as well.  I think the
>  |best one we could think of was:
>  |
>  |    the "control" side for the result of posix_openpt()
>  |
>  |    the "subordinate" side for the result of ptsname() and open(),
> 
> You know, (In)Subordination has a very military touch, with
> exclamation mark many may have heard it.  Also in traditional
> (white western world) education as such.  Like in first the
> pizzle, then the bull pizzle, maybe.  So to say.  In my ears this
> sounds more aggressive and weird than slave, in a technical
> combination of master/slave, ever could.
> Also isn't it a bit submissive here; it is under control, but
> other than that.
> 
>  |    "/dev/pts" still makes sense, etc
>  |
>  |    we would rename our "/dev/ptmx" device file the "manager
>  |    driver" rather than the "master"
>  |
>  |We would strongly consider using the same shift as other projects,
>  |but I think only if they actually make sense; e.g., the "terminal"
>  |and "pseudoterminal" end doesn't really stand out as completely
>  |clear.
> 
> Manager sounds strange here, i always liked manager/worker
> terminologie for threads, and used them like that (and am the
> opinion that .. but that is something different and has sailed),
> but for a pseudo terminal?  I think that if the standard wants to
> be future proof manager should be avoided.  These guys induce
> strange, ruthless and devastating decisions which destroy life on
> earth (as we used to know it), so i for one do not want to be
> harassed by such a term.

Was this discussion concluded yet?

Question: was there ever an intention that a pty master-slave pair
should resemble two real terminals connected to each other?  (e.g., two
serial ports on the same machine, cabled together).


POSIX seems pretty vague as to whether the pty master counts as a
terminal or not.  In Linux, it has many but not all of the properties
of a terminal.  It's not at all clear whether this is intentional, and
I don't know whether other implementations behave similarly.

The main distinctions I'm aware of are that the pty master cannot become
the controlling terminal of any process, and that both master and slave
have rather weird dialin/hangup semantics which appear rather ad-hoc and
don't map nicely onto the behaviour of physical terminal lines.

The master also has a few extra ioctls at its disposal for managing the
pair.

Other stuff does work identically on the pty master and slave though,
such as setting termios modes.  I have a vague memory of successfully
setting ECHO on both ends...


IMHO, the real problem here is that pty devices are underspecified,
and counterintuitive in some areas.  Changing the nomenclature won't fix
that.

Plus, renaming things won't kill off the old terminology, and with both
naming schemes in circulation, people are likely to be even more
confused than they were to start with, no?

Cheers
---Dave