unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk \(man-pages\) via Libc-alpha" <libc-alpha@sourceware.org>
To: Geoff Clare <gwc@opengroup.org>,
	austin-group-l@opengroup.org,
	Steffen Nurpmeso <steffen@sdaoden.eu>
Cc: "Michael Kerrisk \(man-pages\)" <mtk.lists@gmail.com>,
	Florian Weimer <fweimer@redhat.com>,
	linux-man <linux-man@vger.kernel.org>,
	"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
	mtk.manpages@gmail.com, enh <enh@google.com>,
	Joseph Myers <joseph@codesourcery.com>
Subject: Re: Pseudoterminal terminology in POSIX
Date: Wed, 5 Aug 2020 22:34:48 +0200	[thread overview]
Message-ID: <fc30d132-72ad-a3c6-fdd1-3b2c2f9a603e@gmail.com> (raw)
In-Reply-To: <20200805142049.GA17848@localhost>

[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

  parent reply	other threads:[~2020-08-05 20:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05 11:21 Pseudoterminal terminology in POSIX Michael Kerrisk via Libc-alpha
2020-08-05 13:51 ` Steffen Nurpmeso
     [not found]   ` <20200805142049.GA17848@localhost>
2020-08-05 20:34     ` Michael Kerrisk (man-pages) via Libc-alpha [this message]
     [not found]     ` <CAP1RCkjrqKGJmh6f637D=yGuhev7ae5QJkMjv5a8iHo4X33NFw@mail.gmail.com>
     [not found]       ` <1d8c5e6e96fbdd47ce143a566b57db2c803d4898.camel@gnu.org>
2020-08-05 20:34         ` Michael Kerrisk (man-pages) via Libc-alpha
     [not found]         ` <21048.1596645536@jinx.noi.kre.to>
     [not found]           ` <CAH7i3LrNvBo3indixGyJgS2_4F9r3cd3kOiDgPK8m-ZXj1a0zg@mail.gmail.com>
     [not found]             ` <874bfe40-5f05-151d-42b3-482baacbf0b2@gmail.com>
     [not found]               ` <CAH7i3LpXZxwaLQTY=XK8zM4jWYHSiy1feA6ZLE-mT-ZiJNak5A@mail.gmail.com>
2020-08-11  8:31                 ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-08 23:18 ` Larry Dwyer via Libc-alpha
2020-08-10 13:20   ` Joerg Schilling
2020-08-10 18:10     ` Zack Weinberg
2020-08-10 18:17       ` Samuel Thibault
2020-08-10 18:21         ` Samuel Thibault
2020-08-11  8:32       ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-10 13:58   ` Thor Lancelot Simon
2020-08-11  8:31     ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-11 11:51       ` Thor Lancelot Simon
2020-08-11 14:20         ` Michael Kerrisk via Libc-alpha
2020-08-12 14:37       ` Thor Lancelot Simon
2020-08-11  8:32   ` Michael Kerrisk (man-pages) via Libc-alpha
2020-08-11 17:29     ` Joshua M. Clulow via Libc-alpha
2020-08-12 13:19       ` Steffen Nurpmeso
2020-08-18 16:10         ` Dave Martin
2020-08-18 16:44           ` enh via Libc-alpha
2020-08-11 11:17   ` Dirk Fieldhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc30d132-72ad-a3c6-fdd1-3b2c2f9a603e@gmail.com \
    --to=libc-alpha@sourceware.org \
    --cc=austin-group-l@opengroup.org \
    --cc=enh@google.com \
    --cc=fweimer@redhat.com \
    --cc=gwc@opengroup.org \
    --cc=joseph@codesourcery.com \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.lists@gmail.com \
    --cc=mtk.manpages@gmail.com \
    --cc=steffen@sdaoden.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).