Mark descriptor as terminal for the -t test

Mark descriptor as terminal for the -t test

[Sebastian Gniazdowski]

Hello
One can test if a descriptor is connected to terminal with -t.

if [ ! -t 0 ]; then
    echo "Stdin is not from terminal"
fi

Having a descriptor X, pointing to a file or to a process (with >(cmd)
redirection), is it possible to make it look like terminal? For the
test -t to pass?

The goal is: make this more robust:
  exec > >(tee -a ~/$$.out)

It works, catches output of commands, however e.g. from vim, message
about "output is not to a terminal" appears.

Best regards,
Sebastian Gniazdowski

Re: Mark descriptor as terminal for the -t test

[Bart Schaefer]

Just returned from a trip where I had limited email access, so several
things to catch up on, maybe over a few days ...

On May 13, 10:18am, Sebastian Gniazdowski wrote:
} Subject: Mark descriptor as terminal for the -t test
}
} Having a descriptor X, pointing to a file or to a process (with >(cmd)
} redirection), is it possible to make it look like terminal? For the
} test -t to pass?

No.  The "is a terminal" state is at the OS level; the descriptor must
refer to a tty device file.

} The goal is: make this more robust:
}   exec > >(tee -a ~/$$.out)
} 
} It works, catches output of commands, however e.g. from vim, message
} about "output is not to a terminal" appears.

Almost any interactive command will be confused or broken by that usage.
This is the reason that e.g. the "script" command exists.

I presume this is related to your "ztrace" project.  I fear you're doomed
to failure with that one, except in a very simple cases.

It is theoretically possible to do something with the "zpty" module, but
keeping all the I/O in sync when an interactive command wants curses-type
functionality is extremely tricky, and you have to manage all keyboard
signals to propagate them through.

Re: Mark descriptor as terminal for the -t test

[Sebastian Gniazdowski]

On 2 June 2016 at 06:45, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On May 13, 10:18am, Sebastian Gniazdowski wrote:
> } Subject: Mark descriptor as terminal for the -t test
> }
> } Having a descriptor X, pointing to a file or to a process (with >(cmd)
> } redirection), is it possible to make it look like terminal? For the
> } test -t to pass?
>
> No.  The "is a terminal" state is at the OS level; the descriptor must
> refer to a tty device file.

isatty() is a call that probably all programs use to test for the state

> } The goal is: make this more robust:
> }   exec > >(tee -a ~/$$.out)
> }
> } It works, catches output of commands, however e.g. from vim, message
> } about "output is not to a terminal" appears.
>
> Almost any interactive command will be confused or broken by that usage.
> This is the reason that e.g. the "script" command exists.

A robust program, the script. Recalls asciinema.

Turns out the commands are not so confused. Either they assume there
is no terminal, and strip terminal control codes from output, or
ignore the fact (e.g. vim) and work well.

> I presume this is related to your "ztrace" project.  I fear you're doomed
> to failure with that one, except in a very simple cases.

Turned out the isatty() == 0 is a useful thing. If a program is
capable of stripping his output out of control codes, let it do it. If
not, then it's a problem in general. So I was striving for a more
problematic situation. Could implement use of following program:

http://www.andre-simon.de/doku/ansifilter/en/ansifilter.php

to strip control codes, but have no motivation to do so. The dream of
"reuse output without mouse" is better to be implemented at terminal
level. Ctrl-Space to invoke sophisticated selection and completion
mechanism, to paste-in some part of what terminal has seen up to this
moment. iTerm2 folks did numerous of things in their v3 release, but
there is no reusing of output, no ztrace-like interface.

Best regards,
Sebastian Gniazdowski

Re: Mark descriptor as terminal for the -t test

[Bart Schaefer]

On Jun 3,  6:30pm, Sebastian Gniazdowski wrote:
}
} A robust program, the script. Recalls asciinema.

The other way around, really: "script" has been around for decades.

} Turns out the commands are not so confused. Either they assume there
} is no terminal, and strip terminal control codes from output, or
} ignore the fact (e.g. vim) and work well.

The third thing that some programs do is to look harder for a terminal,
e.g. examine all of stdin/out/err with isatty() and direct all I/O to
whichever of them is found to be a terminal.  (Recall the discussion of
a few weeks ago regarding descriptors opened for both read and write
even though in practice they are only used for one or the other.)

} to strip control codes, but have no motivation to do so. The dream of
} "reuse output without mouse" is better to be implemented at terminal
} level.

Output that is screen-oriented rather than stream-oriented is also not
suitable for re-use anyway, at least not directly.

You might also look at Functions/Zle/keeper for a related idea.