7 ms·

Terminals Are Sexy

147 points by turrini 8y ago

deleted 8y ago
[deleted]
cjohansson 8y ago
eshell is a terminal emulator inside Emacs that is written in Elisp. It also have support for ssh/ftp/sftp and more via tramp, highly recommend. You can multiplex it and have powerline without much effort
- edw 8y ago
  Yes but can you run Emacs inside it?
  - cjohansson 8y ago
    Not inside eshell but inside term and ansi-term that are more complete terminal emulators inside Emacs. Though they lack tramp-support
crispinb 8y ago
Human sexuality may be famously plastic, but this could be going a bit far.
- InGodsName 8y ago
  Sexy = attractive
- coldtea 8y ago
  You'd be surprised
  - crispinb 8y ago
    Perhaps I should consider myself fortunate to have maintained a decent foothold in the non-tech world.
- knolax 8y ago
  I'm surprised .sexy is a tld at all.
notafraudster 8y ago
This is a lot to take in. Not sure if you're the author, OP, but in case the author is reading: Where would you suggest someone starts? (Note: Don't answer here! Use your answer to shape the organization of information on the site!) For example, I use ZSH. Should I switch to fish? The list suggests I'd be sacrificing power and the ability to write scripts but gaining, uh, intelligence and user-friendliness? Is that true? Then there's a ton of stuff about customizing ZSH. I know that oh-my-zsh is the most popular but I did not find it especially performant so I never really looked in to using modular components of it. Now I know there are 50 other guides I could read? Maybe I want a plugin manager. antigen is a plugin manager, maybe it'll be more performant than oh-my-zsh? But what about antibody, which is "faster" and "simpler"? But zgen is "lightweight". Are weight and speed connected? What about weight and simplicity? Maybe I should switch to pure, which is "pretty, minimal, and fast". Then I moved on to my terminal. Currently I use iTerm 2, which "does amazing things". But maybe I should switch to Terminator, which is the "future of terminals". Or MacTerm, which is "powerful". Or Alacritty, which is GPU accelerated? (Isn't iTerm 2? I don't know?) I went to macOS package managers. I use homebrew because it's what every webpage for everything I want to install says. Should I get fink instead? Macport, I think is old, but it "simplifies the installation of software". I thought homebrew was pretty simple, but I guess it could be simpler? Then for text editors, I've never been good at emacs-fu, so I often use nano. Maybe I should replace with micro, which is "modern and intuitive"? Or jed, which is "freely available". I don't think I paid for nano, maybe I did. How does a curated list of Terminal frameworks, plugins, and resources differ from an uncurated one? Can the author give some example of a framework, plugin, or resource that was considered but not included because of the curation? I suspect the things that I know aren't included simply weren't considered to begin with. Maybe I'm wrong. Most of this criticism applies to every awesome list that gets linked, of course.
- snazz 8y ago
  There are only so many adjectives in circulation. More seriously: it’s hard to put together a list like this because so many things are subjective. Maybe you prefer fish because it gets rid of some of the dumb things required for a POSIX-compatible shell, but I prefer zsh because it has every feature and the kitchen sink. I don’t know, and neither does the person putting together the list.
sergioro 8y ago
"neovim - Literally the future of vim." I'd rather say Vim 8.2 is the future of Vim.
- throwawaylolx 8y ago
  Yeah, I find the list needlessly opinionated and not sure how it adds to e.g. https://www.google.com/search?q=awesome+cli https://www.google.com/search?q=awesome+cli
  - dickeytk 8y ago
    that's not editorializing, that is neovim's tagline: https://neovim.io/ https://neovim.io/
edhelas 8y ago
http://linuxbrew.sh/ http://linuxbrew.sh/ but… why? We have distributions that are providing perfectly packaged things like Debian/Arch/RedHat. I find already Homebrew hacky on macOS so why porting it on Linux distributions :D Is there anyone on HN using it, I'd be curious to know what are the advantages.
- selectodude 8y ago
  It's for people who don't have root access to a remote terminal (super computer users, generally) but want more up to date packages.
  - Zarel 8y ago
    It's also useful for people who do have root access to a terminal, remote or otherwise, but want more up-to-date packages. Some packages (my favorite example is youtube-dl) are useless if they're not up-to-date. And sometimes the new version has a feature that's really important to you. I'm using it for ripgrep and node, for instance. ripgrep isn't available in apt, and the node version in apt is incredibly outdated. There's a reason most software these days tells you to curl an installer and pipe it to bash, and that's because distro package managers never have the latest version. Here's ripgrep's apt installation instructions: curl -LO https://github.com/BurntSushi/ripgrep/releases/download/0.10.0/ripgrep_0.10.0_amd64.deb sudo dpkg -i ripgrep_0.10.0_amd64.deb There's no way I'm memorizing that. I'll have to google 'ripgrep' copy/paste it from the readme each time. Linuxbrew is just so much easier: brew install ripgrep
    - anothergoogler 8y ago
      youtube-dl is on PyPI https://pypi.org/project/youtube_dl/ https://pypi.org/project/youtube_dl/
      - Zarel 8y ago
        Neat! That could be useful in certain situations. In case you're suggesting Linuxbrew is unnecessary (I don't think you are, but just in case), there's definitely something way more convenient about just using Linuxbrew to install everything, than to track down what software is best installed from what repository.
classichasclass 8y ago
I guess I'm the last of the tcsh troglodytes. C-shell derivatives don't even get mentioned in these things to say "don't use it" anymore.
- jonathankoren 8y ago
  tcsh was the thing to use back in the days of multiuser systems and ytalk. Knowing when your friends were logged, and command correction were killer. I’m still happy that macs shipped with tcsh as default for a while. But I switched to bash when I stopped carrying enough to switch the default shell. Maybe I’ll switch to fish. I do love its snarky tagline.
partycoder 8y ago
spacemacs and spacevim = slow Can be slower than an IDE
Zarel 8y ago
It mentions TotalTerminal, which hasn't been properly supported since OS X 10.10, and outright doesn't work on versions of macOS newer than 10.12. I really miss TotalTerminal. I've been forced to switch to iTerm, the only other way I can find to get a hotkey terminal, but it's an extremely noticeable difference to switch from the overall fastest terminal to the overall slowest: https://danluu.com/term-latency/ https://danluu.com/term-latency/
- somada141 8y ago
  Interesting read, never considered iTerm to be slow and I'm so grateful it exists but maybe I'm not as hardcore a terminal user as I thought I was :).
  - gnyman 8y ago
    I'm not sure this is still the case or has been for some time. The maintainer of iTerm2 commented on it here https://gitlab.com/gnachman/iterm2/issues/5922 https://gitlab.com/gnachman/iterm2/issues/5922 and here https://news.ycombinator.com/item?id=14800195 https://news.ycombinator.com/item?id=14800195. Also recent versions include a metal renderer[3] (not sure if it's enabled by default) which might be even faster, I have been running it for some time but have not noticed much difference. Another reason why it might be hard to notice is also because when one is using ssh you anyways have the network latency so might be one is simply trained not to react to latency in terminals as much. [3] https://gitlab.com/gnachman/iterm2/wikis/Metal-Renderer https://gitlab.com/gnachman/iterm2/wikis/Metal-Renderer
    - Zarel 8y ago
      For me, the most noticeable delay is in opening the hotkey window. I have animation disabled, and there's still a few hundred milliseconds between when I press the hotkey, and when iTerm appears.
    - somada141 8y ago
      Haha good call! I might well have trained myself to ignore a small latency :D
dannypgh 8y ago
Every time I encounter a tmux recommendation it has me pondering whether it's worth learning minicom. When I first read the author's rationale for tmux it rubbed me the wrong way, because the main feature they dismiss as cruft- the ability to use it as a terminal emulator for a serial port - is something I still find myself using from time to time. Is tmux really so much nicer than screen it's worth learning minicom?
- corndoge 8y ago
  Matter of preference. I use tmux as a multiplexer and minicom for serial consoles. Mostly because minicom works out of the box more frequently than screen does, even with proper baud rate and other options set sometimes screen just shits the bed when used for serial. Never had any issues with minicom, it just works.
- pmoriarty 8y ago
  You could also learn screen instead of minicom. screen supports communication over serial.
  - dannypgh 8y ago
    Perhaps I was unclear: screen is what I use now (and have used for quite a long time) and I haven't moved away from it because I actually use and value the support of serial consoles.
- theonemind 8y ago
  I doubt it? An apparently old version of the tmux FAQ listed these advantages: a clearly-defined client-server model: windows are independent entities which may be attached simultaneously to multiple sessions and viewed from multiple clients (terminals), as well as moved freely between sessions within the same tmux server; a consistent, well-documented command interface, with the same syntax whether used interactively, as a key binding, or from the shell; easily scriptable from the shell; multiple paste buffers; choice of vi or emacs key layouts; an option to limit the window size; a more usable status line syntax, with the ability to display the first line of output of a specific command; a cleaner, modern, easily extended, BSD-licensed codebase. Which is all well enough. However, the way I use screen and tmux, I hardly notice any difference. I don't care about BSD vs GPL. I don't try to script either from the shell, mostly just interactive use. I don't really care whether it uses vi or emacs keybindings. I mostly use the system clipboard. I use one pretty standard status line on either one and I have already memorized what I usually type to get it. i think screen still has some features that tmux doesn't, and vice versa, but I don't have a very strong affinity for either one. They even have similar keybindings. Give them the same prefix key and statusline/statusline color and if I'm not paying close attention, I might not realize which one I'm using.
partycoder 8y ago
"lexis" is the same as # unix wc -w # powershell Measure-Object -Word
- anothergoogler 8y ago
  Yea but it's written in JavaScript.
  - crehn 8y ago
    And has 51 dependencies. Some of this JavaScript stuff is amazingly ridiculous.
    - partycoder 8y ago
      npm itself has more dependencies. https://github.com/npm/cli/blob/latest/package.json https://github.com/npm/cli/blob/latest/package.json
FavouriteColour 8y ago
I love this. Just reading the list make me happy. I would contribute: xmlstarlet Manipulate xml documents http://xmlstar.sourceforge.net/ jq Manipulate json documents https://stedolan.github.io/jq/ screen Terminal multiplexer (like tmux) https://www.gnu.org/software/screen/ imagemagick Manipulate images https://www.imagemagick.org/ ffmpeg Manipulate video https://www.ffmpeg.org/ gifski Create high-quality gifs https://gif.ski/ Oh I see I can make a pull request!
- deleted 8y ago
  [deleted]
realbarack 8y ago
I had a product idea (maybe it is even a business idea) a while back to do shell autocompletion based on an autocompletion engine which was trained across multiple users. Kind of like a cloud-connected fzf. The problem this solves is that the ecosystem of unix tools is so massive it's impossible to wrap your head around it. Most of us just pick our tools and end up at a local optimum. But with that sort of thing seeing the way other people have solved a problem is very useful. I still think this would be so useful but the privacy situation is very sketchy. If I could come up with a solution to that I might try to build it.
schaefer 8y ago
came for some actual, physical (preferably sexy) terminals. was disappoint.
- fphhotchips 8y ago
  I was ready for an article on the latest in airport and train station architecture. Was also disappoint.
sharpercoder 8y ago
I hate non-discoverable UI's. The first thing I do with any software, is click through all possible menu's, windows, ribbons, whatever. After some time, I usually get quite a grasp on what the software is capable of. The two notable exceptions are textbased UI's (terminals, dsls, ...) and softwar requiring domain specific knowledge (e.g. geomodeling software, specific 3D modeling software, ...). I never understood the appeal for terminals. Often (Microsoft's Powershell is a notable exception) the syntax is full of incomprehensible abbreviations, the syntax is wildly inconsistent, the syntax contains hard to remember acronyms... No, for me, terminals and most textbased interfaces will never be as usable as GUIs.
- stouset 8y ago
  As a generality, GUIs can do only the tasks they were designed to do, and little more. Text-based terminals allow simple composition of tasks into arbitrarily-powerful pipelines. Terminals might not have discoverability, but in terms of sheer power they wildly outmatch GUIs for many tasks.
- joobus 8y ago
  With zsh and a good completion script (e.g. one provided by oh-my-zsh), tab completion will discover every option for a command. And the man page will list all the options as well.
- drewrv 8y ago
  I hate them too. There are a number of things wrong with them, discoverability is one of them but what really gets me is tracking state. Why do I need to guess at the state of things inside my head as I'm running commands, or query the machine to tell me, when the actual state is sitting there in memory the whole time?
- lostctown 8y ago
  Well hopefully this is not a sentiment that continues to grow in the technical community. All nice things have a cost. For all the efficiency gained from the web-view, consider the cost of building the web-view, maintaining it, hosting, and the other myriad of frontend activities. Contrast that process with downloading a few popular libraries, coding up some methods, exposing them via a cli lib, and then publishing to one of the many package managers. I can do the later in an afternoon, but I may never release if I think all my users should have a web-view. I suspect if all technical users simply stopped considering text based ui acceptable, we'd actually have less quality software overall. There are too many programmers like myself, who can make decent programmatic interfaces, but simply can't put together a usable web-interface to save their life.
black-tea 8y ago
A pet peeve of mine is confusing the terms "terminal", "shell", "CLI" etc. They are not interchangeable and the distinction is important to understand. - shell: the "top level" user interface for the operating system. Can be text-based or graphical, command-line based or point and click etc. It's how you do things once you've loaded an OS. Examples: sh, bash, zsh, fish, eshell (emacs). - terminal: A hardware device for input/output of text. Originally teletype machines (ttys) but later used CRT monitors instead of a printer. Example: DEC VT100, - terminal emulator: a piece of software that emulates a terminal. Examples: xterm, GNOME Terminal - CLI: command-line interface. A user interface based on typing commands one line at a time. Does not include text-based UIs like htop etc. Examples: git, curl. - TUI: text-based UI. Essentially a GUI but works on more advanced terminals (ie. not actual ttys). Examples: htop, emacs, vim.
purplezooey 8y ago
Still no good terminal calendar program that can sync with o365.
qwerty456127 8y ago
Command-line interface can indeed be very convenient for many tasks, nevertheless a properly designed GUI can always be made a way better than a TUI so I can see no reason to stick with terminal-based editors given a choice. And I wish people would stop dichotomizing command-line and GUI and start integrating their capabilities to build something synergic. I.e. I'd love to have a terminal featuring powerful inteligent pop-up autocompletion and correction, visual shell command construction assistance, file choice dialogue (so I could choose a file the GUI way and get its name pasted into the command) etc.
alisa12 8y ago
Hi for Everyone! I"ve got an interesting news. Would you like to have an interesting pastime in internet. http://bit.ly/love-ok http://bit.ly/love-ok Click here.

147 points by turrini 8y ago

deleted 8y ago

[deleted]

eshell is a terminal emulator inside Emacs that is written in Elisp. It also have support for ssh/ftp/sftp and more via tramp, highly recommend. You can multiplex it and have powerline without much effort

edw 8y ago
Yes but can you run Emacs inside it?
- cjohansson 8y ago
  Not inside eshell but inside term and ansi-term that are more complete terminal emulators inside Emacs. Though they lack tramp-support

crispinb 8y ago

Human sexuality may be famously plastic, but this could be going a bit far.

InGodsName 8y ago
Sexy = attractive
coldtea 8y ago
You'd be surprised
- crispinb 8y ago
  Perhaps I should consider myself fortunate to have maintained a decent foothold in the non-tech world.
knolax 8y ago
I'm surprised .sexy is a tld at all.

notafraudster 8y ago

This is a lot to take in. Not sure if you're the author, OP, but in case the author is reading: Where would you suggest someone starts? (Note: Don't answer here! Use your answer to shape the organization of information on the site!) For example, I use ZSH. Should I switch to fish? The list suggests I'd be sacrificing power and the ability to write scripts but gaining, uh, intelligence and user-friendliness? Is that true? Then there's a ton of stuff about customizing ZSH. I know that oh-my-zsh is the most popular but I did not find it especially performant so I never really looked in to using modular components of it. Now I know there are 50 other guides I could read? Maybe I want a plugin manager. antigen is a plugin manager, maybe it'll be more performant than oh-my-zsh? But what about antibody, which is "faster" and "simpler"? But zgen is "lightweight". Are weight and speed connected? What about weight and simplicity? Maybe I should switch to pure, which is "pretty, minimal, and fast". Then I moved on to my terminal. Currently I use iTerm 2, which "does amazing things". But maybe I should switch to Terminator, which is the "future of terminals". Or MacTerm, which is "powerful". Or Alacritty, which is GPU accelerated? (Isn't iTerm 2? I don't know?) I went to macOS package managers. I use homebrew because it's what every webpage for everything I want to install says. Should I get fink instead? Macport, I think is old, but it "simplifies the installation of software". I thought homebrew was pretty simple, but I guess it could be simpler? Then for text editors, I've never been good at emacs-fu, so I often use nano. Maybe I should replace with micro, which is "modern and intuitive"? Or jed, which is "freely available". I don't think I paid for nano, maybe I did. How does a curated list of Terminal frameworks, plugins, and resources differ from an uncurated one? Can the author give some example of a framework, plugin, or resource that was considered but not included because of the curation? I suspect the things that I know aren't included simply weren't considered to begin with. Maybe I'm wrong. Most of this criticism applies to every awesome list that gets linked, of course.

snazz 8y ago
There are only so many adjectives in circulation. More seriously: it’s hard to put together a list like this because so many things are subjective. Maybe you prefer fish because it gets rid of some of the dumb things required for a POSIX-compatible shell, but I prefer zsh because it has every feature and the kitchen sink. I don’t know, and neither does the person putting together the list.

sergioro 8y ago

"neovim - Literally the future of vim." I'd rather say Vim 8.2 is the future of Vim.

throwawaylolx 8y ago
Yeah, I find the list needlessly opinionated and not sure how it adds to e.g. https://www.google.com/search?q=awesome+cli https://www.google.com/search?q=awesome+cli
- dickeytk 8y ago
  that's not editorializing, that is neovim's tagline: https://neovim.io/ https://neovim.io/

edhelas 8y ago

http://linuxbrew.sh/ http://linuxbrew.sh/ but… why? We have distributions that are providing perfectly packaged things like Debian/Arch/RedHat. I find already Homebrew hacky on macOS so why porting it on Linux distributions :D Is there anyone on HN using it, I'd be curious to know what are the advantages.

selectodude 8y ago
It's for people who don't have root access to a remote terminal (super computer users, generally) but want more up to date packages.
- Zarel 8y ago
  It's also useful for people who do have root access to a terminal, remote or otherwise, but want more up-to-date packages. Some packages (my favorite example is youtube-dl) are useless if they're not up-to-date. And sometimes the new version has a feature that's really important to you. I'm using it for ripgrep and node, for instance. ripgrep isn't available in apt, and the node version in apt is incredibly outdated. There's a reason most software these days tells you to curl an installer and pipe it to bash, and that's because distro package managers never have the latest version. Here's ripgrep's apt installation instructions: curl -LO https://github.com/BurntSushi/ripgrep/releases/download/0.10.0/ripgrep_0.10.0_amd64.deb sudo dpkg -i ripgrep_0.10.0_amd64.deb There's no way I'm memorizing that. I'll have to google 'ripgrep' copy/paste it from the readme each time. Linuxbrew is just so much easier: brew install ripgrep
  - anothergoogler 8y ago
    youtube-dl is on PyPI https://pypi.org/project/youtube_dl/ https://pypi.org/project/youtube_dl/
    - Zarel 8y ago
      Neat! That could be useful in certain situations. In case you're suggesting Linuxbrew is unnecessary (I don't think you are, but just in case), there's definitely something way more convenient about just using Linuxbrew to install everything, than to track down what software is best installed from what repository.

classichasclass 8y ago

I guess I'm the last of the tcsh troglodytes. C-shell derivatives don't even get mentioned in these things to say "don't use it" anymore.

jonathankoren 8y ago
tcsh was the thing to use back in the days of multiuser systems and ytalk. Knowing when your friends were logged, and command correction were killer. I’m still happy that macs shipped with tcsh as default for a while. But I switched to bash when I stopped carrying enough to switch the default shell. Maybe I’ll switch to fish. I do love its snarky tagline.

partycoder 8y ago

spacemacs and spacevim = slow Can be slower than an IDE

Zarel 8y ago

It mentions TotalTerminal, which hasn't been properly supported since OS X 10.10, and outright doesn't work on versions of macOS newer than 10.12. I really miss TotalTerminal. I've been forced to switch to iTerm, the only other way I can find to get a hotkey terminal, but it's an extremely noticeable difference to switch from the overall fastest terminal to the overall slowest: https://danluu.com/term-latency/ https://danluu.com/term-latency/

somada141 8y ago
Interesting read, never considered iTerm to be slow and I'm so grateful it exists but maybe I'm not as hardcore a terminal user as I thought I was :).
- gnyman 8y ago
  I'm not sure this is still the case or has been for some time. The maintainer of iTerm2 commented on it here https://gitlab.com/gnachman/iterm2/issues/5922 https://gitlab.com/gnachman/iterm2/issues/5922 and here https://news.ycombinator.com/item?id=14800195 https://news.ycombinator.com/item?id=14800195. Also recent versions include a metal renderer[3] (not sure if it's enabled by default) which might be even faster, I have been running it for some time but have not noticed much difference. Another reason why it might be hard to notice is also because when one is using ssh you anyways have the network latency so might be one is simply trained not to react to latency in terminals as much. [3] https://gitlab.com/gnachman/iterm2/wikis/Metal-Renderer https://gitlab.com/gnachman/iterm2/wikis/Metal-Renderer
  - Zarel 8y ago
    For me, the most noticeable delay is in opening the hotkey window. I have animation disabled, and there's still a few hundred milliseconds between when I press the hotkey, and when iTerm appears.
  - somada141 8y ago
    Haha good call! I might well have trained myself to ignore a small latency :D

dannypgh 8y ago

Every time I encounter a tmux recommendation it has me pondering whether it's worth learning minicom. When I first read the author's rationale for tmux it rubbed me the wrong way, because the main feature they dismiss as cruft- the ability to use it as a terminal emulator for a serial port - is something I still find myself using from time to time. Is tmux really so much nicer than screen it's worth learning minicom?

corndoge 8y ago
Matter of preference. I use tmux as a multiplexer and minicom for serial consoles. Mostly because minicom works out of the box more frequently than screen does, even with proper baud rate and other options set sometimes screen just shits the bed when used for serial. Never had any issues with minicom, it just works.
pmoriarty 8y ago
You could also learn screen instead of minicom. screen supports communication over serial.
- dannypgh 8y ago
  Perhaps I was unclear: screen is what I use now (and have used for quite a long time) and I haven't moved away from it because I actually use and value the support of serial consoles.
theonemind 8y ago
I doubt it? An apparently old version of the tmux FAQ listed these advantages: a clearly-defined client-server model: windows are independent entities which may be attached simultaneously to multiple sessions and viewed from multiple clients (terminals), as well as moved freely between sessions within the same tmux server; a consistent, well-documented command interface, with the same syntax whether used interactively, as a key binding, or from the shell; easily scriptable from the shell; multiple paste buffers; choice of vi or emacs key layouts; an option to limit the window size; a more usable status line syntax, with the ability to display the first line of output of a specific command; a cleaner, modern, easily extended, BSD-licensed codebase. Which is all well enough. However, the way I use screen and tmux, I hardly notice any difference. I don't care about BSD vs GPL. I don't try to script either from the shell, mostly just interactive use. I don't really care whether it uses vi or emacs keybindings. I mostly use the system clipboard. I use one pretty standard status line on either one and I have already memorized what I usually type to get it. i think screen still has some features that tmux doesn't, and vice versa, but I don't have a very strong affinity for either one. They even have similar keybindings. Give them the same prefix key and statusline/statusline color and if I'm not paying close attention, I might not realize which one I'm using.

partycoder 8y ago

"lexis" is the same as # unix wc -w # powershell Measure-Object -Word

anothergoogler 8y ago
Yea but it's written in JavaScript.
- crehn 8y ago
  And has 51 dependencies. Some of this JavaScript stuff is amazingly ridiculous.
  - partycoder 8y ago
    npm itself has more dependencies. https://github.com/npm/cli/blob/latest/package.json https://github.com/npm/cli/blob/latest/package.json

FavouriteColour 8y ago

I love this. Just reading the list make me happy. I would contribute: xmlstarlet Manipulate xml documents http://xmlstar.sourceforge.net/ jq Manipulate json documents https://stedolan.github.io/jq/ screen Terminal multiplexer (like tmux) https://www.gnu.org/software/screen/ imagemagick Manipulate images https://www.imagemagick.org/ ffmpeg Manipulate video https://www.ffmpeg.org/ gifski Create high-quality gifs https://gif.ski/ Oh I see I can make a pull request!

deleted 8y ago
[deleted]

realbarack 8y ago

I had a product idea (maybe it is even a business idea) a while back to do shell autocompletion based on an autocompletion engine which was trained across multiple users. Kind of like a cloud-connected fzf. The problem this solves is that the ecosystem of unix tools is so massive it's impossible to wrap your head around it. Most of us just pick our tools and end up at a local optimum. But with that sort of thing seeing the way other people have solved a problem is very useful. I still think this would be so useful but the privacy situation is very sketchy. If I could come up with a solution to that I might try to build it.

schaefer 8y ago

came for some actual, physical (preferably sexy) terminals. was disappoint.

fphhotchips 8y ago
I was ready for an article on the latest in airport and train station architecture. Was also disappoint.

sharpercoder 8y ago

I hate non-discoverable UI's. The first thing I do with any software, is click through all possible menu's, windows, ribbons, whatever. After some time, I usually get quite a grasp on what the software is capable of. The two notable exceptions are textbased UI's (terminals, dsls, ...) and softwar requiring domain specific knowledge (e.g. geomodeling software, specific 3D modeling software, ...). I never understood the appeal for terminals. Often (Microsoft's Powershell is a notable exception) the syntax is full of incomprehensible abbreviations, the syntax is wildly inconsistent, the syntax contains hard to remember acronyms... No, for me, terminals and most textbased interfaces will never be as usable as GUIs.

stouset 8y ago
As a generality, GUIs can do only the tasks they were designed to do, and little more. Text-based terminals allow simple composition of tasks into arbitrarily-powerful pipelines. Terminals might not have discoverability, but in terms of sheer power they wildly outmatch GUIs for many tasks.
joobus 8y ago
With zsh and a good completion script (e.g. one provided by oh-my-zsh), tab completion will discover every option for a command. And the man page will list all the options as well.
drewrv 8y ago
I hate them too. There are a number of things wrong with them, discoverability is one of them but what really gets me is tracking state. Why do I need to guess at the state of things inside my head as I'm running commands, or query the machine to tell me, when the actual state is sitting there in memory the whole time?
lostctown 8y ago
Well hopefully this is not a sentiment that continues to grow in the technical community. All nice things have a cost. For all the efficiency gained from the web-view, consider the cost of building the web-view, maintaining it, hosting, and the other myriad of frontend activities. Contrast that process with downloading a few popular libraries, coding up some methods, exposing them via a cli lib, and then publishing to one of the many package managers. I can do the later in an afternoon, but I may never release if I think all my users should have a web-view. I suspect if all technical users simply stopped considering text based ui acceptable, we'd actually have less quality software overall. There are too many programmers like myself, who can make decent programmatic interfaces, but simply can't put together a usable web-interface to save their life.

black-tea 8y ago

A pet peeve of mine is confusing the terms "terminal", "shell", "CLI" etc. They are not interchangeable and the distinction is important to understand. - shell: the "top level" user interface for the operating system. Can be text-based or graphical, command-line based or point and click etc. It's how you do things once you've loaded an OS. Examples: sh, bash, zsh, fish, eshell (emacs). - terminal: A hardware device for input/output of text. Originally teletype machines (ttys) but later used CRT monitors instead of a printer. Example: DEC VT100, - terminal emulator: a piece of software that emulates a terminal. Examples: xterm, GNOME Terminal - CLI: command-line interface. A user interface based on typing commands one line at a time. Does not include text-based UIs like htop etc. Examples: git, curl. - TUI: text-based UI. Essentially a GUI but works on more advanced terminals (ie. not actual ttys). Examples: htop, emacs, vim.

purplezooey 8y ago

Still no good terminal calendar program that can sync with o365.

qwerty456127 8y ago

Command-line interface can indeed be very convenient for many tasks, nevertheless a properly designed GUI can always be made a way better than a TUI so I can see no reason to stick with terminal-based editors given a choice. And I wish people would stop dichotomizing command-line and GUI and start integrating their capabilities to build something synergic. I.e. I'd love to have a terminal featuring powerful inteligent pop-up autocompletion and correction, visual shell command construction assistance, file choice dialogue (so I could choose a file the GUI way and get its name pasted into the command) etc.

alisa12 8y ago

Hi for Everyone! I"ve got an interesting news. Would you like to have an interesting pastime in internet. http://bit.ly/love-ok http://bit.ly/love-ok Click here.