Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What do you love/hate about terminals? Would you change them?

news.ycombinator.com

Post reply on HN
Print view View original

151–160 of 204 posts

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#151

Post by gwbas1c »

geocar wrote: post #114
gwbas1c wrote: post #104

I'm a Mac User, and honestly I think the Mac terminal is fine and there's very little room for improvement. But if I were to improve here's a few of the things that I would do: - Make it easier to know what the current process is and kill it if it goes haywire. An out-of-control process can trap control C and ignore it. I really hate digging into activity monitor to kill a process when I just want to keep the same te…

> An out-of-control process can trap control C and ignore it. Many programs that trap SIGINT won't trap SIGQUIT so ^\ will still kill the process. Even if they do, if ^Z works then kill -9 %1 will be good. > A better display of my current working directory, and my current git branch. These items should be displayed at the edge of the window, not inside the terminal itself. MY prompt has been \$ for ages, and I've man…

What you suggest requires a significant amount of learning and relies on hidden commands. What I'm suggesting is narrowing the use case of the terminal and making it more user-friendly without relying on non obvious hidden tricks.

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#152

Post by skrebbel »

swiley wrote: post #23
skrebbel wrote: post #16

I think that the autocomplete story is abysmal. Modern IDEs can tell me exactly what can follow after a certain piece of text, and even the best tab completion in terminals is limited, ugly, and text-mode for no good reason. Some protocol for a real dropdown rendered in the style of the OS, plus a standard data format that allows tool builders to specify options, their meanings and the kinds of allowed parameters in…

>Modern IDEs can tell me exactly what can follow after a certain piece of text I don't think that's computable in a terminal.

It could be, if there was a standard format or protocol by which a shell can ask a command what flags/options make sense in what context.

A bit like how man pages are a standard format for static docs, every tool could ship "autocomplete files" which tell a shell how to build the autocomplete. These files could even contain runnable code (in sh or something) without an additional security risk - after all, they came with a program that you're about to run :-)

I'm sure there's all kinds of challenges with this when you go deeper, but when even a relatively lightweight tool like VS Code can give me perfect C# IntelliSense on every major OS, I find it a bit abysmal that unzipping a file from the terminal is non-trivial.

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#153

Post by hungerstrike »

I hate terminals because they're completely undiscoverable and they depend on you typing each character exactly right or things could blow up.

Give me a good discoverable, safe UI over a terminal any day.

The only good thing about a terminal is that flexibility you get by piping programs together. GUIs can (and do) have the same kind of flexibility but it's not as standardized so I guess another good thing about terminals is that there are some simple standards.

Other than that though, I'd throw away terminals forever if I could.

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#154

Post by geocar »

gwbas1c wrote: post #151
geocar wrote: post #114

Earlier quoted context omitted.

> An out-of-control process can trap control C and ignore it. Many programs that trap SIGINT won't trap SIGQUIT so ^\ will still kill the process. Even if they do, if ^Z works then kill -9 %1 will be good. > A better display of my current working directory, and my current git branch. These items should be displayed at the edge of the window, not inside the terminal itself. MY prompt has been \$ for ages, and I've man…

What you suggest requires a significant amount of learning and relies on hidden commands. What I'm suggesting is narrowing the use case of the terminal and making it more user-friendly without relying on non obvious hidden tricks.

"Significant" is relative.

What I suggest is available today: and for the cost in time of reading my message will resolve a third of your issues.

I don't know what you mean by "non obvious hidden tricks". People learn what control-C does because they read the manual; because someone shows them. Likewise with other keys and job control. Or the tab key. Or google. Very few things are obvious, and you can find what they are by putting them in a room with a potato and watching: If the potato can figure it out, then it was obvious.

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#155

Post by saulrh »

terminal-survey wrote: post #147
saulrh wrote: post #119

If I were building a terminal from scratch... Hm. Attempts to improve the terminal are not backwards-compatible or do not otherwise provide a clean upgrade path. I would love to use one of those fancy graphical terms that comes up on HN every now and then, but because they only work with a special toolchain that speaks its language and its language only there's no way they'll ever gain critical mass and take off. Any…

> I would love to use one of those fancy graphical terms that comes up on HN every now and then One of these (Black Screen) is among the many inspirations with which we started. > Any attempt to improve the terminal has to be something that I could switch to on a whim and then gradually grow into. Backwards-compatibility is a hard requirement for us because of that. And oh boy, it causes a lot of pain. > I've essenti…

> Backwards-compatibility is a hard requirement for us because of that. And oh boy, it causes a lot of pain.

Yeah, it's a bitch. Sorry. :( I've seen one or two "rewrite everything and make it better enough that people switch" big-bang efforts succeed - I run fish, 'nuff said - but this is a rather more invasive change, and it doesn't have good fallbacks ("run bash for ten seconds").

I'm not sure there is a good solution here, not when I look at it from the formal languages perspective. The existing language (what's relevant to current functionality) contains nearly all sequences of elements of the available alphabet (bytes), so anything we do will collide with something. Nobody was able to leave a specific exception to permit extension the way HTML did when it decided to silently ignore unrecognized tags. Though maybe the ANSI "application program command" escape codes might be usable? Either way, this really seems like a question of what you're going to have to choose to break, and that's never fun.

> This is a huge fear of mine. We need to find a way of opening the GUI can-of-worms without ending up with terminals that are as bloated as contemporary web browsers.

Pretty much. You have a titanic advantage, since you don't have to deal with styles at all and can probably start over with a non-hierarchical layout based on integer constraint satisfaction, but you're still stuck trying to bootstrap a small OS/environment. Maybe "only" the size of something like a well-designed video game modding API (factorio, kerbal space program, MMOs, etc).

Heh, emacs might be another thing you could look at, they're having some of these issues themselves.

------------------------------

What are the "killer apps" for these features? `cat foo.jpg` is a parlor trick; what could you do that'd actually make me want to switch? We'd probably be looking for small but effective quality-of-life things that anyone can use - for example, fish-shell got me with "it just works" completion and syntax highlighting.

Hmm. Every tabular output (ps, ls, df, docker, random stuff massaged with awk and cut) magically having sortable columns in the original data, no rerunning the command with a different flag? Parse `--help` to make a checkbox/textbox for each flag and a "do it" button that assembles the resulting invocation? A standardized set of "quick invocations" that a command can give to the terminal to be quickly invoked with something like `M-[[:digit:]]`, so that, say, the suggestions from `command-not-found` would be a single keystroke away, or ls could provide "cd to directory 1, 2, 3"?

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#156

Post by geoelectric »

skrebbel wrote: post #148
adambyrtek wrote: post #59

Earlier quoted context omitted.

Pretty much any modern shell (bash, zsh, fish, etc) provides command line completion.

If you really think the completion in current shells is the best there can be then I think you lack imagination. I don't want remembered commands, I want the terminal to tell me what stuff means. I want it to tell me what makes sense in which context. Like the IntelliSense when coding Java or C#. Docs at your fingertips, all relevant options (and none else) available, etc. This is incomparable to the kind of autocomp…

fish shell does exactly what you say, out of the box. c/p below:

  ~/.l/share: tar --                                                               
  --absolute-paths               (Don't strip leading /)
  --after-date                   (Only store newer files)
  --append                       (Append files to archive)
  --atime-preserve               (Keep access time)
  …and 58 more rows
As others have mentioned, zsh can be tuned to perform similarly. fish is nice in that if you don't have explicit completions for options set up it actually parses man pages.

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#157

Post by chainsaw10 »

terminal-survey wrote: post #93
baq wrote: post #57

i've got ~20 bashes open in various tmux configurations. the amount of times i lost command history is infuriating (e.g. due to reboot or whatever). context-sensitive completion (not necesarrily tab completion, mind you) is very basic compared to IDEs. mouse support would be good if it was actually useful. copy and paste is useful. zoom in/out (think c--/c-+/c-0 in browsers) would be nice sometimes, especially when i…

> i've got ~20 bashes open in various tmux configurations. the amount of times i lost command history is infuriating (e.g. due to reboot or whatever). zsh does (has an option to) commit commands to the history file immediately when you execute the command. Makes me hate bash even more when I have to use it occasionally on a server.

You can do something similar with bash. If you set PROMPT_COMMAND='history -a', it'll append to the history file right after the command completes (because the prompt command is run as the prompt is printed).

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#158

Post by bitwize »

btschaegg wrote: post #134
bitwize wrote: post #115

Earlier quoted context omitted.

So basically, you hate ASCII and Unicode.

Not really, just the way that keyboard input is mapped to a charset (like ANSI or Unicode). A keyboard is not a device that is 100% compatible with any character set (mainly because it is an array of keys that have an arbitrary meaning in a charset). The current terminal architecture enforces any application to adopt its mapping of key combination to code points, which doesn't really make sense, at least from an inpu…

What you say about keyboards is true for PC keyboards, but was not always, historically, the case. Terminals always sent the ASCII code of the pressed key(s), and especially in early terminals, all CTRL really did was to mask off the highest bits of the transmitted code leaving a value between 0-31 -- the ASCII control range. That's why ^I is TAB and ^[ is escape.

If we implemented what you proposed, terminal emulators wouldn't be terminal emulators anymore -- they'd be some sort of generic input and output framework. While we're at it, why don't we include another API to take advantage of the high-color framebuffer displays most modern computers enjoy rather than just displaying a grid of fixed-width text characters. Oh look, we've just reinvented X11. Again (see: Wayland).

Or how about no, because it's yet another library dependency in what should be a straightforward terminal program, and the whole solution breaks when the program is talking to a real live terminal (as Linux programs can still actually do) because there is no "underlying key event" from a terminal. And if you are assuming an environment like X11 or Wayland, just write an X11 or Wayland program and be done with it. (Both vim and Emacs have taken this approach, and AFAIK support keybindings of the type you describe while running in graphical mode.)

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#159

Post by d0lph »

JdeBP wrote: post #125
d0lph wrote: post #106

Earlier quoted context omitted.

I actually kind of like it, powershell also has -eq, and there's no chance of mixing up assignment and equality operators.

You mix up the := operator with the = operator? (-: There's no chance of mixing them up with the "test" command, note, which is what ajkjk was talking about (even though xe erroneously attributed this to the Bourne Again shell language), because the test command has no assignment operator. Whereas what it does have is a whole bunch of syntactic gotchas that bite people with depressing regularity. * Miss quoting varia…

"Real" languages use "=" and "==" ;)

Was unfamiliar with the minefield of bash issues, still, I do like the -eq operator, even if bash implements it poorly.

Re: Ask HN: What do you love/hate about terminals? Would you change them?

#160

Post by otron »

hollerith wrote: post #140
beefhash wrote: post #49

> - What do you love about terminals? The cursor is (generally) an absolute source of truth: Terminals usually behave very predictably. A good terminal does not get in my way or have any bells and whistles. Text goes in, output goes out, there's support for whatever the application needs wrt graphical capabilities and cursor manipulation. That's it. I don't want to have to deal with "oh god I accidentally clicked on…

>Anything related to mouse support, . . . are anti-features How does mouse support harm you? The change I'd most like to see to Apple's Terminal.app is that when I want make an edit to the middle of a command line that has not been sent to the shell yet, I can use the pointing device to move the cursor to the location of the intended edit. How would that change harm you? Why isn't it enough that you are able to work…

>The change I'd most like to see to Apple's Terminal.app is that when I want make an edit to the middle of a command line that has not been sent to the shell yet, I can use the pointing device to move the cursor to the location of the intended edit.

I recall being able to do this by holding down the alt key as I left clicked where I wanted the cursor to be relocated.

There's nothing wrong with mouse support in itself. Being able to move the cursor, select text, and in general interface with the OS or an application using a mouse is great. However being _forced_ to use the mouse for any kind of general OS or application interfacing feels like an injustice. A macOS specific example would be moving a window between desktops. The last time I used macOS there was no native way to do this without using the mouse. I had to drag the window to the desired desktop (either by dragging it towards the edge of the current desktop or by going to the desktop overview mode and dragging it onto the desired desktop).

Post reply on HN