71–80 of 197 posts
Earlier quoted context omitted.
control+u for line-kill is probably a recent thing, a random PDF of "The Unix Programming Environment" (Kernighan & Pike, 1984, p.6) has @ as the line-kill character (and # is erase which these days may or may not be control+? (linux often does something wrong with the delete key, unlike the *BSD)).
TOPS-20 used ^U. (That's where BSD got it, along with ^W, whence it percolated into other *nix.)
There's been plenty of times that I catted a binary file and broke my terminal settings. Sometimes fixable by running `clear` (without being able to see what I'm typing), sometimes not. And I know PuTTY has a setting for what string is returned in response to some control code, that iirc per standard can be set from some other code. . In general, in-band signaling allows for "fun" tricks. . +++
Two tips, if I may: Ctrl-l is easier to type. And `reset` is equally hard to type on a broken terminal, but more effective.
Earlier quoted context omitted.
Yes. It’s called the X Window System and it’s been around since the ‘80s. Also the problem here isn’t that iterm2 is trying to emulate terminals, it’s that it’s trying to do something more over the same network connection without making changes to the ssh protocol.
X11 or any network transparent graphics protocol doesn't solve the problems that a terminal solves. how do you pipe data through multiple applications in one command using a GUI for example? nobody has been able to solve that in a practical way yet. what we really want is being able to pipe semantic data that can be output to some kind of graphical device/interface that uses that semantic information to display the d…
How about Arcan?
Ah yes, the well known c+aliFIo shell script that every developer has. Inside the commonly used "ace" directory.
This article is sensationalist. And constructed by an LLM. It's well known that cat'ing binary files can introduce weird terminal escape codes into the session. Not surprised that iTerm's SSH integration is not security perfect.
Is it a problem with "cat" or a terminal problem? If I wrote my own version of cat in C, simply reading and displaying a single TXT character at a time, wouldn't I see the same behavior?
Give this one MS-DOS shell headline would be " why I never am using Microsoft again" or something dramatic like that. It is a problem in iterm, Apple's overlay, not in the cat program. Program. At least from Reading the article. That's what I got
cat is a file concatenation utility. UNIX people know to view text files with more.
The title is sensationalist; cat is fine. What is unsafe is iTerm's ssh integration, which is pretty obviously unsafe, because it includes a side control channel that is not cleanly separated from the the data stream. Don't use it, use normal ssh, and all should be fine.
Earlier quoted context omitted.
Graphics. They're network transparent, and take over the terminal. Terminal apps were obsolete once we had invented the pixel. Unix just provides no good way to write one that can be used remotely.
Unix just provides no good way to write one that can be used remotely well that's the issue, isn't it? the graphics options that we have are slow and complex, and they don't solve the problems like a terminal and therefore the terminal persist.
Is ghostty vulnerable?
OTOH, in iTerm2, surprising new features seem to be welcome, if not now, in recent memory. https://news.ycombinator.com/item?id=40458135
- ssh conductor
- AI features almost forced on us until the community complained
- clickable links
I just want a dumb, reliable terminal. Is that too much to ask?