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.0 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,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 b92dce91 for ; Fri, 8 Feb 2019 00:15:53 +0000 (UTC) Received: (qmail 5100 invoked by alias); 8 Feb 2019 00:15:35 -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: 44060 Received: (qmail 15508 invoked by uid 1010); 8 Feb 2019 00:15:35 -0000 X-Qmail-Scanner-Diagnostics: from mail-lf1-f50.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25112. spamassassin: 3.4.2. Clear:RC:0(209.85.167.50):SA:0(-1.9/5.0):. Processed in 2.664224 secs); 08 Feb 2019 00:15:35 -0000 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=baJoK8TsufESrE+NfwAoFNwyPdwXzZ2zn+HYkY1BGvk=; b=YMxDBVmNyhDyPCEC2Vv9dY+3ayNqnSBrwDTkunT+c9lRMqGUd/+9wjWo+75QQMGZQn atoHhgnjQcbgqj/LImZh45gm0iDGb8ZM/IewWs1A90heZk9w5Ormxos+ilNtnw8nl27v tLAd2ofvfsdd4bviqNnwI3e9R7ZJfx8i09J1SXLyAfY/J62w9WJ5d42xPvb8RHrGO7yt htCX4k0AxUD1+iF2R2UVJZu8rreEMB8+juCYZlEuT4ucJQwzqb3AsK3+dYcxlV9tEHMA U2u9MZnRiFFdTlT7VcaaJ9dXlKx8XIe1MwvqQ1Nj3bcXn2vSk4CGLmNC4fte4AbSfcq2 VWZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=baJoK8TsufESrE+NfwAoFNwyPdwXzZ2zn+HYkY1BGvk=; b=Ow1HMWOHlMPWqv48tOA28s6xwYKE+p77l4lY/XIPX73e7jlyPs2bFo5wGn0vbHWkHk TWNeZSApjNQMYxfeTKvvMLZDbd+OyjvksKwqQmKsLjR2AZyHXiTL0nrbWy2xKZzh1EnH p7X+MDSlWtMxSbimq52sDRespAofGkmUwxpJ5W8mvg+wYaQnsX1Yootc6kl225SDs+xR Vu1rw59bkTuIEQPPxGuhqe4n6CM6KvfsHQw5EbrZYd0osoT0Gm+bqBUnel0sF+Wj234g FU4qjTO4KA0nTAymrqVNwFBSAd5reNfwhbcT9w7W5FVhCz9VPRpf2rbQWYXvG35K42Nx EABg== X-Gm-Message-State: AHQUAuZGihHLxPD0IH53GXjbwd+Fr5t4litGpCiw+vTdKgWAtQPIUWqG 1FHutstQIiSg2lTINWc8B1Kz019UmemrKTQ2qoyyeAxe X-Google-Smtp-Source: AHgI3Ia9gBu0CjnSfqJS2Ef9Np6j4H91TYPJ7wvHn2zchlC7uuXAjwDfJ62H0FX980x+OQGOlYtBz7qjFt4GOmQDBAE= X-Received: by 2002:a19:7609:: with SMTP id c9mr12738757lff.107.1549584926733; Thu, 07 Feb 2019 16:15:26 -0800 (PST) MIME-Version: 1.0 From: Bart Schaefer Date: Thu, 7 Feb 2019 16:15:14 -0800 Message-ID: Subject: TTY management To: Zsh hackers list Content-Type: text/plain; charset="UTF-8" There are now at least three threads about terminal handling when the shell has connected the output(s) of a process to something other than a terminal device. There hasn't been any actual wrong information in the responses, but that the question keeps getting repeated anyway indicates to me that it's not being explained fully/clearly enough. 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). This is why there are different results for "cat | vim > ...". Other programs work even harder and will try stderr as well. Still others have a command-line option or other control to force them to behave as if connected to a terminal even when they aren't. Some others always spew terminal control sequences without bothering to check. In no case is this under the control of the shell; if you have a program that doesn't behave as you want, there's nothing the shell can do about it. Regarding isatty() -- as has been explained, this is a system call. It examines an ioctl that is restricted to terminal devices. The shell (or any other process) can't force an arbitrary file descriptor to claim it is a terminal device, that violates the "special files" model under which terminal devices exist. Terminal devices operate using (what to the OS appear to be) hardware-level drivers to mediate the bidirectional data flow. Pseudo-terminals split the master and slave into two descriptors to be able to emulate this, but therefore have to be managed differently; no single descriptor can simply be inherited as stdin/out/err by a forked child as is normally done. The "script" command exists specifically to do this for you. 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. 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.