zsh-workers
 help / Atom feed
From: Sebastian Gniazdowski <sgniazdowski@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: TTY management
Date: Thu, 28 Feb 2019 15:35:06 +0100
Message-ID: <CAKc7PVB_x=WXwTcOocg+sCYiMq=98TCHUxqkc6bkuaZJSfmJhA@mail.gmail.com> (raw)
In-Reply-To: <CAH+w=7Y5TRf-M4yUD4BHa-qgBT11DrinCPMstttiNZeT+gyHHg@mail.gmail.com>

On Fri, 8 Feb 2019 at 01:16, Bart Schaefer <schaefer@brasslantern.com> 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

      reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08  0:15 Bart Schaefer
2019-02-28 14:35 ` Sebastian Gniazdowski [this message]

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKc7PVB_x=WXwTcOocg+sCYiMq=98TCHUxqkc6bkuaZJSfmJhA@mail.gmail.com' \
    --to=sgniazdowski@gmail.com \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/ public-inbox