Re: Pseudoterminal terminology in POSIX

2020-08-05 Thread Oğuz via austin-group-l at The Open Group
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

2020-08-05 Thread Oğuz via austin-group-l at The Open Group
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

2020-08-05 Thread Michael Kerrisk man-pages via austin-group-l at The Open Group
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

2020-08-05 Thread Michael Kerrisk man-pages via austin-group-l at The Open Group
[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

2020-08-05 Thread Michael Kerrisk man-pages via austin-group-l at The Open Group
[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

2020-08-05 Thread Paul Smith via austin-group-l at The Open Group
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

2020-08-05 Thread Oğuz via austin-group-l at The Open Group
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

2020-08-05 Thread Robert Elz via austin-group-l at The Open Group
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

2020-08-05 Thread Robert Elz via austin-group-l at The Open Group
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

2020-08-05 Thread Geoff Clare via austin-group-l at The Open Group
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

2020-08-05 Thread Paul Smith via austin-group-l at The Open Group
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

2020-08-05 Thread Harald van Dijk via austin-group-l at The Open Group

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

2020-08-05 Thread shwaresyst via austin-group-l at The Open Group

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

2020-08-05 Thread Donn Terry via austin-group-l at The Open Group
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

2020-08-05 Thread Geoff Clare via austin-group-l at The Open Group
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

2020-08-05 Thread Geoff Clare via austin-group-l at The Open Group
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

2020-08-05 Thread Steffen Nurpmeso via austin-group-l at The Open Group
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

2020-08-05 Thread Michael Kerrisk via austin-group-l at The Open Group
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/