The VI keyboard shortcuts only make logical sense on a specific Tektronix 4014 terminal that was popular at the time: 46 years ago.
The reason the delete key is broken in like half of all UNIX / Linux systems is because TTY is short for “teletypewriter” — literally a remote type writer banging out text on dead trees. The carriage can go back one character at a time and overwrite an error but it can’t shift printed text on paper.
Windows was developed in an era of CRT displays and delete works with it consistently.
This is why it cracks me up whenever someone talks a out “Linux being the standard”…
The Lear Siegler ADM-3A, actually:
http://www.fabglib.org/group___enumerations_ga67edd9a04814c2...
vi is more than hjkl, and those four non-mnemonic keybindings make up for it by being extremely easy to press for QWERTY users. The vast majority of other commands are perfectly “reasonable” (easy to memorize and not dependent on any antiquated hardware) — append, backward word, change, delete, end of word, find letter, go to (OK, this one is just an arbitrary prefix), and so forth.
And why it makes more sense for \n to be the common Windows line ending because it doesn't have that TTY ancestry.
while true; do echo -n " $(date)\r"; sleep 1; done while true; do printf " $(date)\r"; sleep 1; done printf '\033c'; while true; do echo -en " $(date)\r"; sleep 1; done while true; do echo -en " $(date)\r"; sleep 1; doneAnd xpg_echo is on by default for bash on macOS, so for users on macOS it looks like echo interprets escapes by default.
This is one of the reasons why echo is hopelessly unportable.
And I wish we had a stronger word than unportable for echo. You see that word tossed around on shell scripting resources where the only system it applies to is a 30 year old version of ksh and it only blows up on a full moon when passed a filename with a literal form feed \f, but echo is a practical portability problem.
The Windows Terminal team copied the UNIX terminal "standard" of only clearing the current viewport.
Now, scrolling back "works" in the sense that it shows partial(!) output from previous commands.
Say you have a script that produces 47 screens worth of output, and what you want to see is somewhere in the middle. You can't judge this visually because the scrollbar is inaccurate and there may be other history.
Before you could just 'cls', re-run the script after a change, scroll back, and see only the updated output.
Now, if you do this you'll get 46 screens of superficially identical looking output, with 47 of the output you wanted to see appended to it. This is super confusing.
It has confused me. I've seen other admins be confused as well and copy-paste the wrong thing.
The Microsoft Terminal team debated this and decided to do the wrong thing on purpose and copy the "Linux way" to pander to Linux admins on Windows.
Meanwhile if you go back through the old newsgroups and mailing lists, the same argument was had by Linux people as well, with the same logic I just outlined. They also decided to do the wrong thing. Why? Because they were pandering to UNIX admins coming across to Linux.
Why does UNIX do this? Because of an error in the coding. That is all.
That's why the shiny new Windows Terminal is broken now, to copy an error that was already a copy of an error.
Are you saying this specifically or metaphorically? Because I suspect that there was a rationale behind that decision.
See also https://man7.org/linux/man-pages/man1/clear.1.html which explicitly states that it clears scrollback iff a terminal has a specified capability. Which windows terminal being of CRT origin should have. I think the issue here is actually an intersection of some terminal nuance and windows team who blindly copied the behavior that some linux guys were used to because this knowledge was buried under their gnome defaults.
Iow, no need to blame unix and linux, blame those who picked one (stupid) mode of many and used that as the only mode of operation.
Microsot teams are tainting the Windows developer experience trying to cater to the crowd that has been buying Apple gear for GNU/Linux development.
Busybox clear does not clear scrollback nor does it provide an option to do it. But for example on Alpine where Busybox clear is the default, the ncurses package can be installed to get the ncurses clear.
Which Linux system/terminal/editor are you using where insert mode is not the default?
And the origins of /usr/bin a definite third.
Honest question: How would you design a simple text outputting protocol? Would it be radically different to how it's done today, or would it be the same basic ideas but cleaned up a bit?
I think the biggest danger would be scope creep, but a terminal shouldn’t just be thought of as text.
We already have gtk, qt, appkit, win32, web based frontends for almost everything, and none of them produced anything remotely interoperable. The main advantage of just text is that you see its structure right there in a terminal and may reason about it without referring to the documentation of ps result-related set of structures with all the possible bells and whistles embedded into a large xml-like document schema (which is of course full of legacy and references to other specs, because compatibility and standardization).
If I were to design terminal control today, I might have a separate file descriptor for a pipe that is used for control communication instead of sending control codes inline with the text. And I would definitely have a way to query the capabilities of the terminal directly, instead of looking it up in a terminfo database.
How do you keep that synchronized with the text for things like moving the cursor between words?
The one downside that has is if you separate the formatting from the data you can not recreate the session without keeping time info somehow. So, might need a fix for that.
The only other real alternative I'm aware of is moving the formatting into the API "stream" that communicates using the machine ABI. This is a terrible solution. It's what Windows uses.
You can program this message in the setup screen of the terminal. Maybe you can set up all the terminals in the computer center at night...
You can send Ctrl-E to a user with "write" or "wall"..
This answerback message is actually really old, exists even in mechanical ASR-33 teletypes:
https://en.wikipedia.org/wiki/Enquiry_character
It can also be triggered by the mysterious "here is" key on the ADM-3A.
One would hope that we're past the bad times, but at the same time brand new projects like the kitty terminal emulator let stdout read and delete arbitrary files. And verifying something is safe is just hard, these are not even e.g. memory safety bugs, they're "features".
Oh come on, you know what everyone means. "Output with potentially hostile content".
Right now it seems kitty will happily delete e.g. /tmp/.X11-unix/X0. That sounds fun.
https://sw.kovidgoyal.net/kitty/graphics-protocol/#the-trans...
https://github.com/kovidgoyal/kitty/blob/5541e3c2ff441aea319...
> And no unlike your claim, it does not read them.
strace -e open,openat kitty
printf '\e_Gf=24,s=10,v=20,t=f;%s\e\\' "$(echo -n /etc/passwd|base64)"
openat(AT_FDCWD, "/etc/passwd", O_RDONLY|O_CLOEXEC) = 14Me asking my editor to open /etc/passwd is me asking my editor to do something. My terminal emulator opening files and parsing them and deleting them just because I viewed untrusted content is something different. If you want to make that argument, you need to come up with an example where my editor accesses attacker-controlled files because I opened a random README.md.
Also, please read https://news.ycombinator.com/newsguidelines.html, and shove your attitude.
You very conveniently left out the fact that pretty much anything that views untrusted content has to parse files. If parsing files is where your "security boundaries" lie, I suggest you drop your computer off at the garbage dump. Hell if your editor has a preview function it too will parse untrusted content. Basically, to do anything software has to parse untrusted content. And just by the way, /etc/passwd is not attacker controlled. If the attacker has access to your filesystem already, she really doesnt need to use kitty to do anything. And "opening" README.md will not cause kitty to parse files, unless by "opening" you mean catting without -v. In which case we are back to your mommy told you to know better but you didn't listen.
At this point its obvious you are deliberately trying to spread FUD. I am done interacting with you. Good bye.
The general trick with parsing is to put it in a sandbox that cannot touch files, can only do limited syscalls, etc. This is what e.g. Chrome does.
But yes, it's obvious the Kitty author has no interest in making it more secure ( https://github.com/kovidgoyal/kitty/issues/2084) and it's obviously you take discussions about improving software security as attacks on your person.
Have a good day, sir.
Furthermore the next release of kitty has capability based security for remote control with public key crypto to keep the data safe: https://github.com/kovidgoyal/kitty/discussions/5320
I suggest you find a better place to move the goalposts in your attempts to smear and spread FUD.
r-chive.org
-- from Wikipedia: https://en.wikipedia.org/wiki/MOS_Technology_6581
"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move"