From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by sourceware.org (Postfix) with ESMTPS id C7B303858D35 for ; Mon, 6 Jul 2020 09:13:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C7B303858D35 Received: by mail-ej1-x641.google.com with SMTP id dp18so41590637ejc.8 for ; Mon, 06 Jul 2020 02:13:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:cc:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=usqsTvBPr1mcw9SeUik3/NXUB+DVSb43cVmdPsl0/jg=; b=RH9ZkRWogG5ebP6IdQ0LbdxUBJTbNwSoohjHMbOScmnAaJ6Zkp7tz/MkZDSturjf6m IGJyhW2MqAhJ9HBMqCIQ7foD3nz46dTjFHEfaBD0+334EsDzjv7VkX8PLccHG2VLafoE bEPqsOfUqc11mRd+2uouAE7AM1jR4D24cLcPDyFukGN6Dmd63ZoqpM8jBf7jQG9kwJIO v/mCTb5SWVi1zqzANOba2ukXXdjiBPqdasr4SJf3vsRA0Ams6GReX+dzzJgvcSMQMgV4 X+67BR7aEPxRDM5eqBBREsteiTseZaP+u0eM7YIvgEhhtl8CByna6EgpBGMrXUA+vq1f X0xw== X-Gm-Message-State: AOAM5333mbGpr0H12KzmEL9IaeWnxqZ1gH+R//GBgPnxCV2xuTsVBukH 82KU5gzB3o+6zc61cHyStdM= X-Google-Smtp-Source: ABdhPJw4PjSPTBDIhdz4zskKpPJU3VFTdfMt/e1IW5AyxrqGcmcjwmVoOpyiu0nXTNLzw+pvKO3aWQ== X-Received: by 2002:a17:906:d143:: with SMTP id br3mr40705862ejb.268.1594026802868; Mon, 06 Jul 2020 02:13:22 -0700 (PDT) Received: from ?IPv6:2001:a61:3adb:8201:9649:88f:51f8:6a21? ([2001:a61:3adb:8201:9649:88f:51f8:6a21]) by smtp.gmail.com with ESMTPSA id w18sm16144689ejc.62.2020.07.06.02.13.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jul 2020 02:13:22 -0700 (PDT) Cc: mtk.manpages@gmail.com, Carlos O'Donell , libc-alpha , "Joseph S. Myers" , Florian Weimer , Paul Eggert Subject: Re: Pseudoterminal terminology (was Re: Rename "master" branch to "main"?) To: Zack Weinberg References: From: "Michael Kerrisk (man-pages)" Message-ID: Date: Mon, 6 Jul 2020 11:13:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 06 Jul 2020 09:13:25 -0000 Hello Zack. On 7/4/20 6:52 PM, Zack Weinberg wrote: > On Thu, Jul 2, 2020 at 4:58 PM Michael Kerrisk wrote: >> >>> That said I think this is not as important as other, similar, changes >>> we could make. For instance, the term "master" is used _along with_ >>> "slave" in manual/terminal.texi, and I fully intend to rewrite that >>> chapter to eliminate that terminology as soon as I find the time. >>> Anyone want to beat me to it? >> >> No, but please include me in the discussions. It would be good if libc >> and man-pages could find common terminology. >> >> But I agree also with Joseph that the scope is wider and we should >> think about what terminology POSIX might (be convinced to) switch to. >> >> Unlike Florian, I'm not excessively attached to the need to settle on >> a name that starts with 's'. I think it might be too easy to get into >> knots trying to find names that match 'm' and 's', and one should at >> least allow for the possibility of good names that don't fit with >> those letters; what would be best, IMO, is names that "feel right". > > I agree. In particular I think there is no reason to struggle with > coming up with terms that fit "ptmx" and "pts" because BSD ptys use > totally different device node names anyway (tty[pqrs...]NN and > pty[pqrs...]NN) and there's no hope of finding something that works > with both. (Good point.) > I don't want to commit to terminology until I've had a go at rewriting > the manual, because I think doing the rewrite will be the easiest way > to figure out whether the new terms are good, I think that's a good text engineering approach. I think it's fine to cycle through a number of ideas, rejecting them until something feels "right". > but what I'm currently > thinking is: > > "pty master device" -> "pty line-side device" or "outside device" > "pty slave device" -> "pty host-side device" or "inside device" > /dev/ptmx stands for "pseudoterminal multiplexer" > /dev/pts stand for "pseudoterminals (directory of)" > > Currently I like "line-side" and "host-side" because it seems like a > natural generalization from true terminal device nodes (which are > always host-side) to pseudoterminals (additionally have a line-side > device node). And it can generalize to the relationship between > Linux's /dev/ttyNN and /dev/vcs(a)NN as well. So far, "line-side" and "host-side" don't do it for me. But maybe I just need time to sit with those terms to get used to them. As we consider names, I think it's good to keep in mind the rather diverse set of applications where pseudoterminals are used, including ssh etc. xterm etc. expect tmux script unbuffer I just throw out some ideas (in the order master, slave): "driver" device plus "terminal" device "driver" device plus "client" device "proxy" device plus "terminal" device "proxy" device plus "client" device I'm not arguing that these are better than your terms. (At least, not yet ;-).) But I think it's useful to throw a lot of ideas into the mix, in the hope of sparking further ideas from others. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/