Live data from Hacker News

Terminals Are Sexy

terminalsare.sexy

61–70 of 84 posts

Re: Terminals Are Sexy

#61

Earlier quoted context omitted.

But most commandline languages are inconsistent, have inconsistent abbreviations, have inconsistent command parameter naming/defaults, contain acronyms of incomprehensible words, have plain weird names, contain inconsistent or outright incorrect documentation... A language to do stuff is actually a great thiing, especially if it can produce readable and reproducable objects (programs). However, I get really scared lo…

So? English is horribly inconsistent but you seem to be doing just fine. We know bash etc. aren't ideal. That's why Python was invented. But the reason they stick around is because they are useful and people do use them day to day. Are you really going to forgo language completely just because it doesn't meet your superficial idea of perfection?

Human languages are also forgiving on the receiving side which is not true for computer languages. 1 wrong character and yiu get an error. This is an important difference when discovering and even using it,l.

Re: Terminals Are Sexy

#62

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?

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.

Re: Terminals Are Sexy

#63
post #7

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.

Just discovered it, so I still have to see if it fits my needs, however if I understood what it does, it could be useful to solve a recent problem: after some upgrades (apt, Debian) all my Windows VST audio plugins I used under .wine through LinVST stopped working. not a single one can be used anymore and it seems a newer .wine version is to blame for incompatibility, so I would attempt to create a different user and install a previous wine version locally then move the .wine directory there and see if running the LinVST patcher there will make the plugins useable again. That way I would not touch the system wine installation which runs fine for other things, ditto for the main user .wine directory, while still being able to test a different version.

Re: Terminals Are Sexy

#64

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

Bash & Homebrew & Terminal app & Nano. It’s a local minima.

There’s probably better alternatives, but I’d have to summon the energy to tunnel my way over the barrier.

Re: Terminals Are Sexy

#65

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

Regarding Fish.

A lot of people seem to complain about loosing the ability to write scripts that work on other shells because Fish breaks compatibility.

Well, I’ve been using fish for a couple of years now and besides a couple of things that are very specific to my main computer, the rest of my scripts I build as POSIX as I can. I keep everything on a repo and I can then push/pull things on new machines and have everything available.

One can still execute a `/bin/sh script.sh`. Nothing prevents someone from doing that.

Re: Terminals Are Sexy

#66
post #11

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

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.

I don't know how someone reading the list would understand that "fish ... gets rid of some of the dumb things [what things?] required for a POSIX-compatible [?] shell, but [others] prefer zsh because it has every feature [what features?] and the kitchen sink."

For example, I didn't realize "smart" in the list's vernacular means "deprecates dumb legacy behaviour". Your post is the first time that became obvious to me. Now to figure out what that behaviour is and why I should care and if it impacts performance and and and...

My post wasn't asking the curator to make decisions for me, it was asking them to help me make decisions.

Re: Terminals Are Sexy

#67

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

Speaking of discoverability, I commonly use --help with a command/program that I haven't used before. And if it doesn't have that option, I do dislike it for that.

Re: Terminals Are Sexy

#68

Earlier quoted context omitted.

> But most commandline languages are inconsistent, have inconsistent abbreviations, have inconsistent command parameter naming/defaults, contain acronyms of incomprehensible words, have plain weird names, contain inconsistent or outright incorrect documentation... And how is this different for GUIs? Location / icons / description / ... depends entirely on the application. Some will have hotkey handles, some won't. Sa…

With a language, it is far more important. In a gui I can just click around and see. With tuis, I need to enter a command and hope it is the right syntax.

Yes tuis. But clis commonly have a --help option, and/or a man page.
Post reply on HN