Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: TTY management
- X-seq: zsh-workers 44095
- From: Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: TTY management
- Date: Thu, 28 Feb 2019 15:35:06 +0100
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- 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==
- In-reply-to: <CAH+w=7Y5TRf-M4yUD4BHa-qgBT11DrinCPMstttiNZeT+gyHHg@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAH+w=7Y5TRf-M4yUD4BHa-qgBT11DrinCPMstttiNZeT+gyHHg@mail.gmail.com>
On Fri, 8 Feb 2019 at 01:16, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author