From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 10463fc7 for ; Thu, 28 Feb 2019 14:36:10 +0000 (UTC) Received: (qmail 6808 invoked by alias); 28 Feb 2019 14:35:54 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 44095 Received: (qmail 22297 invoked by uid 1010); 28 Feb 2019 14:35:54 -0000 X-Qmail-Scanner-Diagnostics: from mail-oi1-f177.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25370. spamassassin: 3.4.2. Clear:RC:0(209.85.167.177):SA:0(-2.0/5.0):. Processed in 2.515041 secs); 28 Feb 2019 14:35:54 -0000 X-Envelope-From: sgniazdowski@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.167.177 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FNu4FHfn+DGNs13krjn+RiYRW53uyzN41RrrkQGxbx8=; b=mn2tIv3LWPDH17W8+/YGCADpYTWIwJQMuNH+UnkoGpSOfQdxwpiN8nBpjHiTh5bS7x pBleuEg9JDrHWcfF0Ghmq1njcfKXe2ZQI6rzlKyP0AaAIhEc3RNu3L3iTvL7F9i/pZOS 5/X+79k31fNJkCj5Mvsl45Nzu4plSz8V1oZ7fmWUragZje98HNIlc5USO7X/KcLxiThD YrUPHKgxuYgx3eiOJZNhJAzPKYMlQgxHZbz3/mamJ4YSJo96Z5XF6GELjX+jVXJftNi+ Dvo86tXouV3amjznphQIIil0evkQ7USCGquUr3sSCupQQEAASH2HrOzq/1jM3R0iVfEE GEVA== 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=FNu4FHfn+DGNs13krjn+RiYRW53uyzN41RrrkQGxbx8=; b=MkHbTz/exCr7XrbrtBq5/vgHRXz4E+A+gMnKFCNWl1m1WVLf7Z+qdFlc33MchZladw Go63xZkBXYg+jrtT++dtEo4SovMEuQ+o7RBCnaA7e82YkB3FlJ+PGPhGgNEU4+Oaof8u 2XQgY/y1lEINp7M03Yk2KYOVqQM95AYVpZPTWH2RMr9w55/n6d8rtcUouzGID83o09LP 2qvoAzCiflbYakuokywJ1Qx2tDn5JNP6oBAa7osrDZqVTafyMWY84TewF1DDVEGPUgNT A1aKqzh69Cm9KeIxMm4k13qpSrjC+5R16oYsgw7ifHcLiDyd954Yz6BDkatXjT3pUXTU vZEA== X-Gm-Message-State: AHQUAub1ZVKSwmFVe3jAL/eXLP5bTJjw56DMQH7olkD/BR2uVW26naC7 n4siLoyLXVVtlc8tQ/U9v12sqCoy0t5WysM/913Xaw== X-Google-Smtp-Source: AHgI3IaQVeCEWzDApU1T67Ikjsd7X1t/Zv10bTZFRAZsNYa4/4VrAAsuN8knfbfPOFAGngvKPAKE4tbdzqYoCgDG44c= X-Received: by 2002:aca:fd91:: with SMTP id b139mr8688oii.170.1551364518294; Thu, 28 Feb 2019 06:35:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sebastian Gniazdowski Date: Thu, 28 Feb 2019 15:35:06 +0100 Message-ID: Subject: Re: TTY management To: Bart Schaefer Cc: Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Fri, 8 Feb 2019 at 01:16, Bart Schaefer wrote: > First let's talk about "vim | cat". Programs that expect to use > capabilities of an interactive terminal nearly always make their own > determination of whether they can do so, but how this is done varies a > lot. Vim in particular works very hard to find a terminal - it will > look at both stdin and stdout, and if either of those is a terminal it > will try to interact with that (assuming the descriptor is open for > both reading and writing). I think this works differently, and I have proof for this: % vim | cat > file doesn't yield a working vim like the `vim | cat' does. This means that vim doesn't look for a terminal on stderr or /dev/tty, but that instead it just streams its terminal-codes to the redirected stdout. If the redirected output is still a terminal, then things work, if not (e.g. the >file above), then things don't work. That's why I wanted to just make the isatty() test pass with True. > Regarding isatty() -- as has been explained, this is a system call. > It examines an ioctl that is restricted to terminal devices. (...) > Terminal devices operate > using (what to the OS appear to be) hardware-level drivers to mediate > the bidirectional data flow. Ahso, pity then this would mean that one cannot simply pretend that a descriptor is a tty. > There are actually security-related reasons for this -- think 1980/90s > technology -- you don't want a man-in-the-middle attack capturing a > login exchange from a physical terminal in a computer lab, for > example. Virtual terminal devices came along later and have to > address this differently. Ahso, interesting. > The upshot of this is that, as PWS said, the core shell is not the > place to handle this. If someone wants to find open-source of the > "script" command and turn it into a module, though, that might be > worth considering. What exactly would this module do? -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org