If you want a better experience, use a different shell, simple as that. The reason this becomes so obvious in this scenario, is because script is basically a testimony to how traditional Unix shells are broken. You can only come up with the idea of creating such a program, if the program script should be used for is inherently broken and wrong.
And, I think most of the issues with script command are not shell issues. They are issues caused by using an exact copy of what was typed on the keyboard. What you get is almost like computer typesetting as done by roff, nroff, etc. Given that script comes from the same age as roff this is not surprising.
Congratulations Rosika
You may have found the perfect substitute for script
It should record what you see on the screen, rather than what you type, so no backspaces
It starts a new shell, just to do the scripting.
Did you look at it with less or vi to see if there are control characters? Cat is not a full test.
Will give it a workout
I was talking about the meta level. Why do we even need script? Why is it necessary? Because the shell does not give us enough transparency on what is happening, what happened and perhaps even what has changed. This is the problem and this is why I called it a shell problem.
I must admit, I am surprised at your response.
When I first encountered Bourne shell, it was like an academic challenge. Much more abstract than any of the mainframe interactive systems that preceded it.
It opened the door to a lot of things. It was the first environment I encountered where you could consider using output from one program as input for another. That was made possible by the Unix filesystem treating all files as a byte stream. It was a breakthru.
Things have got far more complex today. Other things like json are changing the way we put things together.
I am not against a new shell, but I would not like to see it go in the Msoft direction where they hide everything that the computer does from the user.
One of the appealing features of Unix and Linux is that they offer most users the chance to dive deeper into things. Some degree of academic appeal needs to be preserved without becoming so abstract that users are repelled.
It is possible to make the code work for either the terminal (ANSI) or a pipeline (no ANSI). The following code tests to see if stdout is a terminal. If it is, it sets the color variables to the required ANSI sequences. If it is not a terminal, no ANSI sequences are generated.
df19127ead