Problem with newer `less`

[agguser]

gwsw/less#834

[MikeMcC399]

This is insufficient information to understand and reproduce your problem. Please re-submit using the Bug report template.

[avih]

TL;DR: node -h | less results in some unexpected behavior of "less".

The issue also happens with js-beautify -h | less and with node -e 'console.log(123)' | less.

It was analyzed that when node exits, it resets the terminal state to the state which it read on init, but that reset happens while less is already/still running, and changes the terminal state under its feet (less may change the terminal state on init, and restore it on exit).

This apparently has always been an issue/race, but a recent version of less changed the timing of the terminal init, and now it results in an issue.

The preferred solution in these cases is that if node only prints to stdout, and stdout is not a tty, then it should not touch the terminal state.

It's unclear what should happen if it prints to other streams beyond stdout (mainly stderr).

[avivkeller]

Isn't that an issue with less, and not Node.js?

[avih]

Isn't that an issue with less, and not Node.js?

That's a rather dismissive question, is it not?

If you believe or think that it's not a problem of node, then you should explain why you think that, and preferably show at least one other non-interactive application (or which can be interactive but currently runs in non-interactive mode) besides node that changes the terminal state when it only prints things to stdout while stdout is not a tty.

Hint: you would have to try very hard to find such application, but when you do, please file a bug with them, similar to this issue with node.

Non-interactive applications should not touch the terminal state (unless that's what they're designed to do - like tput). Not when they start, not when they exit, not anywhere in between, and especially not when their stdout is not a tty.

Otherwise, for instance if they're part of a pipe but not the final pipe-element, then they have no mandate and no business to touch the terminal state, because they don't print to the terminal - stdout is not a tty.

[avivkeller]

That's a rather dismissive question, is it not?

Perhaps it was, unintentionally, but I didn't mean any disrespect. I was merely asking since a less upgrade caused the issue, not a Node.js one. I assure you again, I'm not trying to dismiss the concern.

[avih]

No offense taken, but again, if you think it's not a node problem that node -h | whatever or node -h > help.node touches the terminal state, then you should explain why.

The change in less was the timing of the terminal init. This race always existed, but was not noticed or didn't manifest in the past. Now it has, and the reason was identified as node resetting the terminal state when it exits, even when it's non interactive and its stdout is not a tty.

In general, only interactive applications have mandate to change the terminal state.

Applications which only read stdin and/or print to stdout/stderr typically have no need to touch the terminal state. But even if they do because $reasons, these reasons typically don't exist when they don't even print to the terminal - like when they're part of a pipe but not the final pipe element.

Exceptions do exist, like sudo command | interactive-app where sudo may want to disable terminal echo while it asks for a password, and this is indeed a problem, because in this case sudo is also interactive, and such a pipeline is indeed a recipe for trouble.

But this is not the case with purely non-interactive applications, like js-beautify file.js | less or node -h > file.

[vinc17fr]

But this is not the case with purely non-interactive applications, like js-beautify file.js | less or node -h > file.

A question is whether node knows in advance whether the script is interactive or not, or whether it can avoid the issue for non-interactive scripts without breaking interactive scripts (even partially).

[avih]

A question is whether node knows in advance whether the script is interactive or not

I don't think that's the question, because I don't think "in advance" is relevant. No one can know in advance (it could take code as user input, for instance).

Without being familiar with the internal architecture and initializations, and excluding cases where the application itself changes the terminal settings, the I'd think node itself should only touch the terminal state on first interaction with the terminal (an fd which is a tty) which requires it, and preferably not at all if it's not required.

Typically stdout/stderr don't need touching the terminal state at all, even when the stream is a tty (and even on Windows, if done right - by using WriteConsoleW - note W - and without changing the console codepage to UTF-8).

When reading stdin, if it's a tty, then this typically makes it an interactive application, and if node requires touching the terminal state in such case, then so be it.

The point is to touch the state only if necessary, and only at the first time it's actually necessary. Not blindly.

[vinc17fr]

I disagree, because the user can start typing before the first read by the script. So, for scripts that need raw mode, the terminal should be put in raw mode as soon as possible, i.e. at the beginning.

IMHO, the safest way to avoid the issue would be a declaration at the beginning of the scripts to tell whether the terminal should be put to raw mode. The default could be the current behavior or something smarter.