Hacker News Reader

Comment by jiggawatts | Hacker News Reader

The standard UNIX file system layout exists because hard drives were small at the time and files had to be split across several.

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”…

View on HN

> The VI keyboard shortcuts only make logical sense on a specific Tektronix 4014 terminal

The Lear Siegler ADM-3A, actually:

https://en.wikipedia.org/wiki/ADM-3A#Legacy

Why would you do this to me I'm going to be in a rabbit hole trying to recreate this machine for the next two years. I've been in the hobby long enough that I only get excited about weird things like this keyboard that have historical significance.

FabGL can emulate an ADM 3A on an ESP32:

http://www.fabglib.org/group___enumerations_ga67edd9a04814c2...

> The VI keyboard shortcuts only make logical sense on a specific Tektronix 4014 terminal that was popular at the time: 46 years ago.

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.

Which is why it makes more sense for \r\n to be the *nix line ending - because there is a distinct "carriage return (on same line)" from "line feed (at same carriage position)" operations possible, and combining them together makes carriage return and line feed to put the cursor at the start of a new line.

And why it makes more sense for \n to be the common Windows line ending because it doesn't have that TTY ancestry.

That would make sense except you have them the wrong way around.

I have them the right way around, it's everyone else who has them the wrong way around.

Sometimes when theory doesn't match reality, it's reality that's wrong.

I don't see anything that says which is which in that comment. Just what makes sense.

What's even more nuts about Unix 300-layers-of-tty-emulation \n acting like a CRLF is that \r still works just fine as CR. e.g., you can get a nice little clock with:

  while true; do echo -n "  $(date)\r"; sleep 1; done

I need to use printf to interpret the escape character:

    while true; do printf "  $(date)\r"; sleep 1; done

It might also work with "echo -e".

I like my terminals a little bit cleaner:

    printf '\033c';  while true; do echo -en "  $(date)\r"; sleep 1; done

(don't forget "-e" for echo)

  while true; do echo -en "  $(date)\r"; sleep 1; done

Depends on your echo. Zsh's interpretes escape sequences by default unless the "BSD_ECHO" option is used, bash's doesn't unless "xpg_echo" is on.

And 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.

See https://unix.stackexchange.com/a/65819/55665

Learn something new every day!

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.

Until very recently windows terminal couldn’t select a wrapped line without adding \r\n in between… And it still messes up default color brightness making grey text white until something else messes it back.

Until recently "cls" and "Clear-Host" in Windows Terminal used to actually clear everything so you couldn't accidentally scroll back and see junk that you wanted to get rid of.

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.

ncurses' clear defaults to clearing scrollback and you have to use `-x` to not clear it. I would think most distros use it.

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.

"clear" clears scrollback on my machine. alacritty + zsh on arch linux.

Another thing, is how now we tend to get CLI scripts for what used to be nice Visual Studio wizards.

Microsot teams are tainting the Windows developer experience trying to cater to the crowd that has been buying Apple gear for GNU/Linux development.

And that's good

Not from point of view of Windows devs used to what "Developers, Developers, Developers" meant in practice.

And the worst part is those of us who resemble your remark just download Git Bash et al because Powershell is too verbose anyway.

Because parsing text is so great.

Why does UNIX do this? Because of an error in the coding. That is all.

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.

You know vim has been around for like 30 years now right? And the Windows thing has nothing to do with CRT displays. Windows was built around IBM compatible PCs which had standardized keyboards. It was the only keyboard layout Windows needed to support.

> 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.

Which Linux system/terminal/editor are you using where insert mode is not the default?

Reply on news.ycombinator.com