[2/5] t/test-terminal: avoid non-inclusive language

Commit Message

Linus Arver via GitGitGadget Sept. 16, 2020, 6:10 p.m. UTC

From: Johannes Schindelin <[e-mail]>

In the ongoing effort to make the Git project a more inclusive place,
let's try to avoid names like "master" where possible.

In this instance, the use of the term `slave` is unfortunately enshrined
in IO::Pty's API. We simply cannot avoid using that word here. But at
least we can get rid of the usage of the word `master` and hope that
IO::Pty will be eventually adjusted, too.

Signed-off-by: Johannes Schindelin <[e-mail]>
---
 t/test-terminal.perl | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

Comments

Junio C Hamano Sept. 16, 2020, 9:05 p.m. UTC | #1

"Johannes Schindelin via GitGitGadget" <[e-mail]>
writes:

> From: Johannes Schindelin <[e-mail]>
>
> In the ongoing effort to make the Git project a more inclusive place,
> let's try to avoid names like "master" where possible.

The two sides of a PTY are called 'master' and 'slave', and I
understand there is a push to move away from these words, but
calling one side with an invented name that is used by nobody else
in the context of talking about PTY, while keeping the word used to
call the other side, would lead to confusion.

A better change is to drop "master_" altogether without replacing
the word with anything, and call them just "input", "output" and
"error".  For those who implement the PTY, calling both ends of the
pipe 'master' vs 'slave' may be useful for them, as they are terms
of art they are used to think with.  But as end-users of PTY, the
fact that we are holding the 'master' end, and access to the 'slave'
end is done by asking the 'master' end we hold for the corresponding
'slave', is not that important.  What each of these three PTYs is
used for is much more important.

If $input, $output, and $error are too terse, spell them out as
$term_input, $term_output and $term_error or something like that,
perhaps.

Thanks.

Junio C Hamano Sept. 16, 2020, 9:25 p.m. UTC | #2

Junio C Hamano <[e-mail]> writes:

> "Johannes Schindelin via GitGitGadget" <[e-mail]>
> writes:
>
>> From: Johannes Schindelin <[e-mail]>
>>
>> In the ongoing effort to make the Git project a more inclusive place,
>> let's try to avoid names like "master" where possible.
>
> The two sides of a PTY are called 'master' and 'slave', and I
> understand there is a push to move away from these words, but
> calling one side with an invented name that is used by nobody else
> in the context of talking about PTY, while keeping the word used to
> call the other side, would lead to confusion.
>
> A better change is to drop "master_" altogether without replacing
> the word with anything, and call them just "input", "output" and
> "error".

If we really want to use a replacement word for 'master' instead of
just dropping, I may be inclined to suggest 'parent', in the hope
that PTY implementors will start following what Python folks are
doing, at which time they will give us a synonym for 'slave' method
called 'child' we can use.

Johannes Schindelin Sept. 20, 2020, 3:34 p.m. UTC | #3

Hi Junio,

On Wed, 16 Sep 2020, Junio C Hamano wrote:

> Junio C Hamano <[e-mail]> writes:
>
> > "Johannes Schindelin via GitGitGadget" <[e-mail]>
> > writes:
> >
> >> From: Johannes Schindelin <[e-mail]>
> >>
> >> In the ongoing effort to make the Git project a more inclusive place,
> >> let's try to avoid names like "master" where possible.
> >
> > The two sides of a PTY are called 'master' and 'slave', and I
> > understand there is a push to move away from these words, but
> > calling one side with an invented name that is used by nobody else
> > in the context of talking about PTY, while keeping the word used to
> > call the other side, would lead to confusion.
> >
> > A better change is to drop "master_" altogether without replacing
> > the word with anything, and call them just "input", "output" and
> > "error".
>
> If we really want to use a replacement word for 'master' instead of
> just dropping, I may be inclined to suggest 'parent', in the hope
> that PTY implementors will start following what Python folks are
> doing, at which time they will give us a synonym for 'slave' method
> called 'child' we can use.

Good idea!

Thanks,
Dscho

Junio C Hamano Sept. 21, 2020, 9:12 p.m. UTC | #4

Johannes Schindelin <[e-mail]> writes:

> Hi Junio,
>
> On Wed, 16 Sep 2020, Junio C Hamano wrote:
>
>> Junio C Hamano <[e-mail]> writes:
>>
>> > "Johannes Schindelin via GitGitGadget" <[e-mail]>
>> > writes:
>> >
>> >> From: Johannes Schindelin <[e-mail]>
>> >>
>> >> In the ongoing effort to make the Git project a more inclusive place,
>> >> let's try to avoid names like "master" where possible.
>> >
>> > The two sides of a PTY are called 'master' and 'slave', and I
>> > understand there is a push to move away from these words, but
>> > calling one side with an invented name that is used by nobody else
>> > in the context of talking about PTY, while keeping the word used to
>> > call the other side, would lead to confusion.
>> >
>> > A better change is to drop "master_" altogether without replacing
>> > the word with anything, and call them just "input", "output" and
>> > "error".
>>
>> If we really want to use a replacement word for 'master' instead of
>> just dropping, I may be inclined to suggest 'parent', in the hope
>> that PTY implementors will start following what Python folks are
>> doing, at which time they will give us a synonym for 'slave' method
>> called 'child' we can use.
>
> Good idea!

It is unclear which one of the two you thought a good idea.

Hopefully both are good, but simply dropping "master_" without
attempting to replace would probably be better.

Patch

diff --git a/t/test-terminal.perl b/t/test-terminal.perl
index 46bf618479..680caf48dd 100755
--- a/t/test-terminal.perl
+++ b/t/test-terminal.perl
@@ -81,24 +81,24 @@  sub copy_stdio {
 	die "usage: test-terminal program args";
 }
 $ENV{TERM} = 'vt100';
-my $master_in = new IO::Pty;
-my $master_out = new IO::Pty;
-my $master_err = new IO::Pty;
-$master_in->set_raw();
-$master_out->set_raw();
-$master_err->set_raw();
-$master_in->slave->set_raw();
-$master_out->slave->set_raw();
-$master_err->slave->set_raw();
-my $pid = start_child(\@ARGV, $master_in->slave, $master_out->slave, $master_err->slave);
-close $master_in->slave;
-close $master_out->slave;
-close $master_err->slave;
-my $in_pid = copy_stdin($master_in);
-copy_stdio($master_out, $master_err);
+my $primary_in = new IO::Pty;
+my $primary_out = new IO::Pty;
+my $primary_err = new IO::Pty;
+$primary_in->set_raw();
+$primary_out->set_raw();
+$primary_err->set_raw();
+$primary_in->slave->set_raw();
+$primary_out->slave->set_raw();
+$primary_err->slave->set_raw();
+my $pid = start_child(\@ARGV, $primary_in->slave, $primary_out->slave, $primary_err->slave);
+close $primary_in->slave;
+close $primary_out->slave;
+close $primary_err->slave;
+my $in_pid = copy_stdin($primary_in);
+copy_stdio($primary_out, $primary_err);
 my $ret = finish_child($pid);
 # If the child process terminates before our copy_stdin() process is able to
-# write all of its data to $master_in, the copy_stdin() process could stall.
+# write all of its data to $primary_in, the copy_stdin() process could stall.
 # Send SIGTERM to it to ensure it terminates.
 kill 'TERM', $in_pid;
 finish_child($in_pid);