zsh-workers
 help / color / mirror / code / Atom feed
* Could multios response positively to isatty(1) test?
@ 2019-02-07 13:18 ` Sebastian Gniazdowski
  2019-02-07 15:02   ` Peter Stephenson
  0 siblings, 1 reply; 7+ messages in thread
From: Sebastian Gniazdowski @ 2019-02-07 13:18 UTC (permalink / raw)
  To: Zsh hackers list

Hello,
If at least one of the outputs of the multios-utilizing invocation is
to a terminal, .e.g

print "$fg[blue]A TEST$reset_color" \
    > >(ansifilter >>! "log.txt") 1> >/dev/tty

then could Zshell answer positively to the isatty(1) test for the
application (like e.g. vim) placed the way that the print-command is?
Is this doable?

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Could multios response positively to isatty(1) test?
  2019-02-07 13:18 ` Could multios response positively to isatty(1) test? Sebastian Gniazdowski
@ 2019-02-07 15:02   ` Peter Stephenson
  2019-02-07 16:41     ` Sebastian Gniazdowski
  0 siblings, 1 reply; 7+ messages in thread
From: Peter Stephenson @ 2019-02-07 15:02 UTC (permalink / raw)
  To: zsh-workers

On Thu, 2019-02-07 at 14:18 +0100, Sebastian Gniazdowski wrote:
> Hello,
> If at least one of the outputs of the multios-utilizing invocation is
> to a terminal, .e.g
> 
> print "$fg[blue]A TEST$reset_color" \
>     > >(ansifilter >>! "log.txt") 1> >/dev/tty
> 
> then could Zshell answer positively to the isatty(1) test for the
> application (like e.g. vim) placed the way that the print-command is?
> Is this doable?

The short answer's no.  Implementing pty support in the core shell would
be a bug-prone maintenance disaster.

You're best bet is some kind of pty wrapper (as already discussed) plus
something looking a bit like tee.  This is not stuff you want within zsh
(unless as an add-on --- but zpty is bad enough to maintain, so I wouldn't
recommend even that).

pws


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Could multios response positively to isatty(1) test?
  2019-02-07 15:02   ` Peter Stephenson
@ 2019-02-07 16:41     ` Sebastian Gniazdowski
  2019-02-07 16:46       ` Sebastian Gniazdowski
  2019-02-07 16:50       ` Peter Stephenson
  0 siblings, 2 replies; 7+ messages in thread
From: Sebastian Gniazdowski @ 2019-02-07 16:41 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh hackers list

On Thu, 7 Feb 2019 at 16:10, Peter Stephenson <p.stephenson@samsung.com> wrote:
>
> On Thu, 2019-02-07 at 14:18 +0100, Sebastian Gniazdowski wrote:
> > Hello,
> > If at least one of the outputs of the multios-utilizing invocation is
> > to a terminal, .e.g
> >
> > print "$fg[blue]A TEST$reset_color" \
> >     > >(ansifilter >>! "log.txt") 1> >/dev/tty
> >
> > then could Zshell answer positively to the isatty(1) test for the
> > application (like e.g. vim) placed the way that the print-command is?
> > Is this doable?
>
> The short answer's no.  Implementing pty support in the core shell would
> be a bug-prone maintenance disaster.

Implementing isn;'t necessary – what's needed is the knowledge, that
original fd=1 is a tty,, and conveying that lfurther to the zsh
process realizing the multios – i.e.: conveying only the test answer
to isatty(fd=1), not the terminal implementation. Simple forwarding of
all data to the terminal through non-terminal. works (a good test: vim
| cat).

I wonder what the test (isatty(1)) does. Does it invoke some ioctl()
that somehow reaches the zsh multios-process.. No rather not, but what
then? Maybe some flag on the fd: that is visible to the
application/writer?

> You're best bet is some kind of pty wrapper (as already discussed) plus
> something looking a bit like tee.  This is not stuff you want within zsh
> (unless as an add-on --- but zpty is bad enough to maintain, so I wouldn't
> recommend even that).
>
> pws
>

--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Could multios response positively to isatty(1) test?
  2019-02-07 16:41     ` Sebastian Gniazdowski
@ 2019-02-07 16:46       ` Sebastian Gniazdowski
  2019-02-07 16:50       ` Peter Stephenson
  1 sibling, 0 replies; 7+ messages in thread
From: Sebastian Gniazdowski @ 2019-02-07 16:46 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh hackers list

On Thu, 7 Feb 2019 at 17:41, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> Implementing isn;'t necessary – what's needed is the knowledge, that
> original fd=1 is a tty,, and conveying that lfurther to the zsh
> process realizing the multios – i.e.: conveying only the test answer
> to isatty(fd=1), not the terminal implementation. Simple forwarding of
> all data to the terminal through non-terminal. works (a good test: vim
> | cat).

No, that's isn't logical, correct statement. The correct one:

What's needed is the knowledge, that some (one) of mutlios targets is
a tty, and conveying that information upper to the multios-process, so
that it can mark (?) it's exposed to the writer (the application that
needs a terminal) pipe or FD (unsure)

Confirming test: vim | cat works without any problems, so the exposed
to the application pipe or FD doesn't have to implement a terminal.



-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Could multios response positively to isatty(1) test?
  2019-02-07 16:41     ` Sebastian Gniazdowski
  2019-02-07 16:46       ` Sebastian Gniazdowski
@ 2019-02-07 16:50       ` Peter Stephenson
  2019-02-07 17:55         ` Sebastian Gniazdowski
  1 sibling, 1 reply; 7+ messages in thread
From: Peter Stephenson @ 2019-02-07 16:50 UTC (permalink / raw)
  To: zsh-workers

On Thu, 2019-02-07 at 17:41 +0100, Sebastian Gniazdowski wrote:
> On Thu, 7 Feb 2019 at 16:10, Peter Stephenson <p.stephenson@samsung.com> wrote> Implementing isn;'t necessary – what's needed is the knowledge, that
> original fd=1 is a tty,, and conveying that lfurther to the zsh
> process realizing the multios – i.e.: conveying only the test answer
> to isatty(fd=1), not the terminal implementation.

isatty() is part of the operating system, it doesn't have a way of
checking for "not a real TTY but pretending to be one except actually it
isn't really even pretending to be one but it might work anyway", and I
don't think it would be useful for the shell to behave like that in
general even if it could.

The right fix for pty behaviour is in some kind of terminal interface,
not in the core shell.

pws





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Could multios response positively to isatty(1) test?
  2019-02-07 16:50       ` Peter Stephenson
@ 2019-02-07 17:55         ` Sebastian Gniazdowski
  2019-02-07 18:56           ` Philippe Troin
  0 siblings, 1 reply; 7+ messages in thread
From: Sebastian Gniazdowski @ 2019-02-07 17:55 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh hackers list

On Thu, 7 Feb 2019 at 17:50, Peter Stephenson <p.stephenson@samsung.com> wrote:
>
> On Thu, 2019-02-07 at 17:41 +0100, Sebastian Gniazdowski wrote:
> > On Thu, 7 Feb 2019 at 16:10, Peter Stephenson <p.stephenson@samsung.com> wrote> Implementing isn;'t necessary – what's needed is the knowledge, that
> > original fd=1 is a tty,, and conveying that lfurther to the zsh
> > process realizing the multios – i.e.: conveying only the test answer
> > to isatty(fd=1), not the terminal implementation.
>
> isatty() is part of the operating system, it doesn't have a way of
> checking for "not a real TTY but pretending to be one except actually it
> isn't really even pretending to be one but it might work anyway"

Yes it's a part of the operating system, and i wonder how it works? I
suspect that there's just a flag needed to be set on the FD exposed to
the application.

> The right fix for pty behaviour is in some kind of terminal interface,
> not in the core shell.
>
> pws

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Could multios response positively to isatty(1) test?
  2019-02-07 17:55         ` Sebastian Gniazdowski
@ 2019-02-07 18:56           ` Philippe Troin
  0 siblings, 0 replies; 7+ messages in thread
From: Philippe Troin @ 2019-02-07 18:56 UTC (permalink / raw)
  To: zsh-workers

On Thu, 2019-02-07 at 18:55 +0100, Sebastian Gniazdowski wrote:
> On Thu, 7 Feb 2019 at 17:50, Peter Stephenson <
> p.stephenson@samsung.com> wrote:
> > 
> > isatty() is part of the operating system, it doesn't have a way of
> > checking for "not a real TTY but pretending to be one except
> > actually it
> > isn't really even pretending to be one but it might work anyway"
> 
> Yes it's a part of the operating system, and i wonder how it works? I
> suspect that there's just a flag needed to be set on the FD exposed
> to
> the application.

It boils down to ioctl(TCGETS) on linux if you have to know.
It the same ioctl as the one used for tcsetattr/tcgetattr.

Have you tried:
  script -c "scrapy crawl $options[@]" log.txt

Phil.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-02-07 18:56 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CGME20190207132020epcas2p21907126ab733665c20d5881eb13488ef@epcas2p2.samsung.com>
2019-02-07 13:18 ` Could multios response positively to isatty(1) test? Sebastian Gniazdowski
2019-02-07 15:02   ` Peter Stephenson
2019-02-07 16:41     ` Sebastian Gniazdowski
2019-02-07 16:46       ` Sebastian Gniazdowski
2019-02-07 16:50       ` Peter Stephenson
2019-02-07 17:55         ` Sebastian Gniazdowski
2019-02-07 18:56           ` Philippe Troin

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).