Re: Pseudoterminal terminology in POSIX
6 Ağustos 2020 Perşembe tarihinde Oğuz yazdı: > > > 5 Ağustos 2020 Çarşamba tarihinde Michael Kerrisk (man-pages) < > mtk.li...@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 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.ca...@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 > > *more comfortable* > doesn't make any sense (to me, at least). > > 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. > > >> Thanks, >> >> Michael >> >> > > -- > Oğuz > > -- Oğuz
Re: Pseudoterminal terminology in POSIX
5 Ağustos 2020 Çarşamba tarihinde Michael Kerrisk (man-pages) < mtk.li...@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 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.ca...@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). 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. > Thanks, > > Michael > > -- Oğuz
Re: Pseudoterminal terminology in POSIX
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 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: <1d8c5e6e96fbdd47ce143a566b57db2c803d4898.ca...@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/ Thanks, Michael
Re: Pseudoterminal terminology in POSIX
[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
[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 >> : >> |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 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
On Wed, 2020-08-05 at 23:38 +0700, Robert Elz wrote: > | 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? In the part of my message you elided I was arguing that using the names "provider" and "consumer" doesn't avoid confusion. I guess you proved my point.
Re: Pseudoterminal terminology in POSIX
5 Ağustos 2020 Çarşamba tarihinde Robert Elz via austin-group-l at The Open Group 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: <1d8c5e6e96fbdd47ce143a566b57db2c803d4898.ca...@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. > But if a change is really needed, make it a radical change, and make it > reflect what is really happening, don't try and coerce existing words > to somehow pretend to fit.None of the suggestions that have been > made here is really adequate. > > kre > > -- Oğuz
Re: Mailing list header rewrite adjustment
Date:Tue, 4 Aug 2020 19:57:22 +0100 From:"Andrew Josey via austin-group-l at The Open Group" Message-ID: <08605dfa-f6c7-4eb8-9275-6511fbd37...@opengroup.org> | I will be monitoring and we can revert if it causes issues It causes issues, and is hideous. Please do not abuse the Reply-To header the way that is being done. That is intended for the sender to use to indicate the addresses they would prefer replies to be sent (eg: I could use it here as Reply-To: austin-group-l@opengroup.org which would indicate that replies go just to the list, as I will receive a copy that way, and don't need a second. Or I could add a reply to to (one of) my e-mail addresses, indicating that I'd prefer replies to be sent just to me (which would be appropriate for a message seeking assistance with something where there's no need to bother everyone with a series of replies - I can summarise when done). Or (as I am actually doing with this message, just to see what happens) can set the Reply-To to Reply-To: Andrew Josey , Robert Elz , austin-group-l@opengroup.org which is what most mailers would generate as the default reply address list in the absence of a Reply-To header. kre
Re: Pseudoterminal terminology in POSIX
Date:Wed, 05 Aug 2020 11:28:45 -0400 From:"Paul Smith via austin-group-l at The Open Group" Message-ID: <1d8c5e6e96fbdd47ce143a566b57db2c803d4898.ca...@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). But if a change is really needed, make it a radical change, and make it reflect what is really happening, don't try and coerce existing words to somehow pretend to fit.None of the suggestions that have been made here is really adequate. kre
Re: Pseudoterminal terminology in POSIX
shwaresyst wrote, on 05 Aug 2020: > > On Wednesday, August 5, 2020 Geoff Clare via austin-group-l at The Open Group > wrote: > >> 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 ..."). > The slave side is ancillary to the master, ... I could not disagree more. The slave side is what provides the primary function of a pseudo-terminal, i.e. a device that applications can use just like a "real" terminal. The master side has a supporting role in sending/receiving data to/from the primary device. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: Pseudoterminal terminology in POSIX
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. 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".
Re: More issues with pattern matching
On 05/08/2020 15:54, Geoff Clare via austin-group-l at The Open Group wrote: Harald van Dijk wrote, on 31 Jul 2020: Take the previous example glibc's cy_GB.UTF-8 locale, but with a different collating element: in this locale, "dd" is a single collating element too. Therefore, this must be matchable by bracket expressions. Incorrect. I think you overlooked these statements in XBD 9.3.5 items 2 and 3: It is unspecified whether a matching list expression matches a multi-character collating element that is matched by one of the expressions. It is unspecified whether a non-matching list expression matches a multi-character collating element that is not matched by any of the expressions. My message was indirectly in reply to your message where you claimed that shells were required to support this. I'm very happy to see that this is actually not true, thanks for that. Cheers, Harald van Dijk
Re: Pseudoterminal terminology in POSIX
The slave side is ancillary to the master, sorry, as physical terminals are ancillary to the processor hardware, imo. Inverting the relationship makes it look like it is the intent of the slave side to source the majority of the data, when more often it is only monitoring output data sourced by the master, or producer/processing, side with relatively infrequent input required to be sourced by the monitoring side. For a full duplex connection, the producer side is doing echoes of everything the monitoring side sources along with what it sources unilaterally, so it is primary user of the connection. On Wednesday, August 5, 2020 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 > : > |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 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. > | > | 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. > 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 ..."). -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: Pseudoterminal terminology in POSIX
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? Donn On Wed, Aug 5, 2020 at 7:21 AM 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 > > : > > |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 > 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. > > > | > > |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. > > > 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 ..."). > > -- > Geoff Clare > The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England > >
Re: More issues with pattern matching
Harald van Dijk wrote, on 31 Jul 2020: > > Take the previous example glibc's cy_GB.UTF-8 locale, but with a different > collating element: in this locale, "dd" is a single collating element too. > Therefore, this must be matchable by bracket expressions. Incorrect. I think you overlooked these statements in XBD 9.3.5 items 2 and 3: It is unspecified whether a matching list expression matches a multi-character collating element that is matched by one of the expressions. It is unspecified whether a non-matching list expression matches a multi-character collating element that is not matched by any of the expressions. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: Pseudoterminal terminology in POSIX
Steffen Nurpmeso wrote, on 05 Aug 2020: > > Michael Kerrisk via austin-group-l at The Open Group wrote in > : > |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 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. > | > |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. > 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 ..."). -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: Pseudoterminal terminology in POSIX
Michael Kerrisk via austin-group-l at The Open Group wrote in : |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 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)
Pseudoterminal terminology in POSIX
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 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-1a855e714...@gmail.com/