From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id B0C411F5AE for ; Thu, 30 Jul 2020 20:36:15 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DC7B13890420; Thu, 30 Jul 2020 20:36:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DC7B13890420 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1596141373; bh=sHOs9l3/K6F7LfycNnVOym1V+1P8Mz9mJUC/Blv0iA4=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=diCxMmZ1R9KOqYKfOY0XsJJ7GQwpj08oFVJgkcPhdGalSHGXoJ2L2W86xQ2vveZ4T uD0pRWin8Vcq/zjWJT+3fs5QBR4ZWKGHsPmvnKMVDe8vMOjZfKaTRRRXKrc3RDqDjc z+YjQixHztt0CzvcGATHzJhLa8HnR8kyxxm2jfvU= Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) by sourceware.org (Postfix) with ESMTPS id 156553890419 for ; Thu, 30 Jul 2020 20:36:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 156553890419 Received: by mail-lf1-x141.google.com with SMTP id i19so15674825lfj.8 for ; Thu, 30 Jul 2020 13:36:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sHOs9l3/K6F7LfycNnVOym1V+1P8Mz9mJUC/Blv0iA4=; b=WXwYoiGD646NssPRz5rDAiVuWsjsykLbH9UF/9ediuP87/8Qiu9H/ibkdhJJNoaarE zg8sdwZjXvpyyAAjN/7ht/72+GiX4VoPW70qXZ2HdkPhGkWdhvj7GC0ibp4yNdTrxzSL /vlOYBrPfsAe9fU+esGy7XjQ56GzsxMnJaNJHIT0Ik2VwHPC+OfDbm8GhZOYu7ue/VBR 7QNkNXp84avL4e0hvpHnpNtyQLzVmteAGLBDsR9Nu75wAyJPGL/sKFTVSuVYAHWXqrcv W7qPafizCs1gYDrvQKzCUjcA2zZI7gnHEejsh9uNqzyCLOyu1f+6aO/aUqYfEyEIX8qx b0Fw== X-Gm-Message-State: AOAM531GkFZy0IrWgRyqThjDtxwFtHHj4UaDi3HOrH5MrbE7wgC/slcV CM2I+y9yfKPJhchuABxWDKJl8cI939Ioo9gWuGp+VtkV X-Google-Smtp-Source: ABdhPJzYe+GguGADgcXJa2Ka5GEt7uZyHffofzZPUeBFLD30Wlq/KqeIqiHbcB5iO5YlJq0lECgX1IBIqwt7nWgpoeE= X-Received: by 2002:a19:710:: with SMTP id 16mr184852lfh.171.1596141369641; Thu, 30 Jul 2020 13:36:09 -0700 (PDT) MIME-Version: 1.0 References: <88273c2f-ce21-db54-688d-5bebd4a81ecd@redhat.com> In-Reply-To: Date: Thu, 30 Jul 2020 13:35:57 -0700 Message-ID: Subject: Re: [RFC PATCH] Replacing "master-slave" terminology for pseudoterminals To: "Carlos O'Donell" Content-Type: text/plain; charset="UTF-8" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: enh via Libc-alpha Reply-To: enh Cc: Florian Weimer , linux-man , Linux API , "Michael Kerrisk \(man-pages\)" , "libc-alpha@sourceware.org" , Joseph Myers Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Thu, Jul 30, 2020 at 4:38 AM Carlos O'Donell wrote: > > On 7/30/20 5:16 AM, Michael Kerrisk (man-pages) wrote: > > I know what you mean. One reason for that verbosity is the need to > > clearly distinguish "pseudoterminal device/end" from "pseudoterminal > > device pair". It's hard to avoid being wordy there. > > The perfect is the enemy of the good. My feeling is that as others > write this text in emails or discussions, we'll eventually all settle > on some other short form we find agreeable and then later we can adjust > the man pages to use that. based on my own brief experience, i'm expecting that _code_ will settle on pty and tty. but if you're reading the man pages to understand the concepts -- which are inherently quite confusing -- i think spelling things out in longhand might remain useful in that context. > Until then taking the lead to change this > language is the correct way forward. yeah, definitely. i'd prefer for michael to go first -- since the bionic documentation is basically just a link to man7.org, and even without that he's the canonical source -- but i'm happy to go first and submit my change first if it helps us make progress :-) > -- > Cheers, > Carlos. >