Make console.clear output a control sequence that clears the terminal

[TomasHubelbauer]

What is the problem this feature would solve?

Hi, I am using bun --hot . and it clears the console just fine when used like this, but in my case I am doing nohup bun --hot . & tail -f nohup.out so that I can still listen to the Bun output but have the process keep on running when I close my terminal. This workflow is for a personal project where I am both the developer and the sole user of the web app and this is how I ensure I don't take the app down when I close my editor. By default it always runs and when I happen to be working on it, I get to see the output for troubleshooting. The problem is the default console clearing logic stops working when I do this and even explicitly calling console.clear() doesn't work.

What is the feature you are proposing to solve the problem?

console.log('\x1B[2J\x1B[H');

This clears the whole screen and homes the cursor.
See https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_Sequence_Introducer)_sequences.

What alternatives have you considered?

This is super low priority so the alternative is to not bother doing this. I do not see a downside to this though. Maybe it is not a good idea to print control sequences to file and I just don't know? In any case, I would like to see this done if it is easy and there is no downside and I'll be equally happy to see it rejected if there is a reason it doesn't make sense.

[simylein]

If I may suggest a workaround use a tool like screen which lets bun run in the backend and you can attach and detach at any time using screen -r session-name and ctrl + a plus ctrl + d respectively.
For starting up a screen session use something like screen -dmS session-name bun --hot .
For quitting it either press ctrl + c inside the session or use screen -S session-name -X quit
Oh and if you would like to se your currently running screen sessions use screen -list

screen-demo.mov

[TomasHubelbauer]

@simylein Thanks for the suggestion!

I am aware of screen and tmux. The reason I didn't opt to use them in this case is that I wanted my solution to not require any sort of an interaction from me. In the case of these two, when I am attached to the background process to monitor it and I kill the terminal without detaching the first, they'll be killed.

This is a no-go on this personal project, because I would just end up killing the processes when I kill my editor without remembering. At that point I could just be connected to them directly, the effect would be the same. My solution doesn't suffer from this.

Also, for all my personal projects, I like to stick with out of the box software that comes with macOS. screen does, but it is quite an old version which has some limitations.

In a professional setting, I would absolutely agree that screen or tmux is the right choice.