cmd/pprof: completely unable to use dumb tty

[rsc]

I have TERM=dumb set in my environment. pprof should not be printing ANSI escape codes:

$ go tool pprof x.prof
�[0;31mMain binary filename not available.
�[0mType: alloc_space
Time: Jul 6, 2018 at 4:00pm (EDT)
Entering interactive mode (type "help" for commands, "o" for options)

[rsc]

Actually, the situation is far worse than I realized. If I continue the session:

$ go tool pprof x.prof
�[0;31mMain binary filename not available.
�[0mType: alloc_space
Time: Jul 6, 2018 at 4:00pm (EDT)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top10
��[D �[D��[D �[D��[D �[D��[D �[D��[D �[D

The garbage at the bottom is me typing ^C, because top10 seems to be taking forever. But if I move over to Apple Terminal then top10 runs instantly. I conclude from this that not only is pprof printing garbage to my screen, it has lost the ability to read from standard input!

echo top10 | go tool pprof x.prof still works.

[rsc]

@hyangah Are you still taking care of pprof?

[ianlancetaylor]

May be related to https://golang.org/cl/112436 for #14041.

[robpike]

https://golang.org/cl/112436 is the biggest CL I have ever seen.

[hyangah]

It currently uses golang.org/x/crypto/ssh/terminal and assumes that if terminal.MakeRaw works, terminal is supported.

What's the right way to detect dumb tty? Is checking TERM env var sufficient?

And, what's the easiest way to create a dumb tty environment for testing? (Just setting TERM=dumb doesn't do anything for me :-()

[ianlancetaylor]

For many readline libraries, the environment variable TERM specifies the kind of terminal. This terminal is looked up in (on GNU/Linux systems) /usr/share/terminfo. That defines a set of character sequences corresponding to various capabilities. This all dates back to the long ago, when different terminals had different escape sequences.

TERM=dumb is a terminfo entry that doesn't have any special character sequences. For example, compare the behavior of gdb and TERM=dumb gdb when you type ^L.

At a quick glance, x/crypto/ssh/terminal doesn't use terminfo, but instead assumes that it is running on a VT100. This is mostly fine today as xterms implement the VT100 escape sequence. But using TERM=dumb still ought to avoid any special escape sequences.

[gopherbot]

Change https://golang.org/cl/122597 mentions this issue: cmd/pprof: disable colorization of error message

[hyangah]

Thanks for the info, Ian.

Not wanting to fix x/crypto/ssh/terminal to recognize terminfo now, I checked if we can simply disable the readline feature completely by checking the environment var TERM.

But here is a bad news - 'go tool pprof' sets the "TERM" env var to "dumb" unconditionally.
https://golang.org/src/cmd/go/internal/envcmd/env.go?s=#L46

cl/122597 disables the colorization code that uses the troublesome ANSI escape code.
I don't know how to debug/diagnose the second issue (i.e. unable to read in the input) because I can't set up the identical environment for reproducing the issue.

[ianlancetaylor]

We can change the go tool to only set TERM when invoking non-Go tools. But maybe not for 1.11.

[hyangah]

Reproduced the problem similar to the second issue using emacs shell.
When the enter key is pressed in the interactive mode, the input ends with '\n' in the restricted, dumb terminal mode in emacs. In a regular non-dumb terminal mode, the key is translated to '\r'.

https://github.com/golang/crypto/blob/master/ssh/terminal/terminal.go#L116 uses only '\r' for enter key, so the readline hangs.