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.