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=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 c58864d9 for ; Thu, 7 Feb 2019 16:51:04 +0000 (UTC) Received: (qmail 24585 invoked by alias); 7 Feb 2019 16:50:39 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 23865 Received: (qmail 14925 invoked by uid 1010); 7 Feb 2019 16:50:39 -0000 X-Qmail-Scanner-Diagnostics: from granite.fifsource.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(173.255.216.206):SA:0(-1.9/5.0):. Processed in 3.110012 secs); 07 Feb 2019 16:50:39 -0000 X-Envelope-From: phil@fifi.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Message-ID: Subject: Re: Why multios affects >/dev/tty redirection? From: Philippe Troin To: zsh-users@zsh.org Date: Thu, 07 Feb 2019 08:50:31 -0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.4 (3.30.4-1.fc29) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit On Thu, 2019-02-07 at 14:00 +0100, Sebastian Gniazdowski wrote: > On Tue, 5 Feb 2019 at 17:43, Philippe Troin wrote: > > That's because when you use multios, the stdout (and other multios > > descriptors) are not connected to a real terminal, but to a pipe > > connected to the invoking zsh process, zsh then sends the output to > > multiple files or devices. > > Because scrapy is not connected to a real terminal, it behaves > > differently. > > I wonder if it's not fully on scrappy's side, i.e. that in such > situation there are no actual obstacles in providing a working > terminal-grasping app, which is rather proved by vim | cat working > just normally. I.e. if it's scrapy that does a ttty-test (i.e. calls > isatty()) and decides to provide a limited application. This is again > fully proven by the fact that this command: > > vim > >(ansifilter > ansi.txt) > /dev/tty > > Works as expected – i.e. vim outputs a warning about output being not > to a terminal, and then works without a single flaw, i.e. cursor- > keys, > home, end keys also working fine. Try: cat | vim > >(ansifilter > ansi.txt) > /dev/tty Things don't work as well in this case. > So could Zshell answer positively to the isatty() call, if at least > one of the multios-outputs is a terminal? I think there's a big > meaning, sense in this, however I don't want the email to be verbose. No, because it's the command (and not the shell) that calls isatty() on a random descriptor that should be connected to a terminal in the app's opinion. You could argue that in this case zsh should set-up a pseudo terminal automatically, but: * There are lot of extra semantics whose behavior is unclear in this case. For example, terminal related signal and window sizing ioctls have to be translated/forwarded between the top level terminal and the emulated pty. * Zsh has no way of knowing that a command will interact with the terminal. In short, it's not a good idea. Have you investigated the script command? It may do what you need, and it's standard. Phil.