Show HN: A single command terminal configuration installer | Hacker News Reader

Show HN: A single command terminal configuration installer

noobs-term.com

51 pointsaaronkjones37 comments

The last thing an inexperienced terminal user should be doing is installing a bunch of software without understanding how it fits together, how it is used, or how it is actually configured. If you want to understand your terminal stack, build it; don't have it built for you.

The better approach is to start from a basic setup. For example, with vim, don't use vim-sensible right off the bat. Instead, just use vim. If a need arises, research what you can set up to address it. If you are curious about what is out there, read through the source of plugins like vim-sensible, taking each option, reading the docs for it, learning a bit of vimscript as needed, and only adding stuff to your vimrc if you really understand what you are adding. Don't add a bunch of things all at once. Do one at a time, and try it out for a while.

My thinking is it's easier to start out with a solid foundation that I think the "sensible" and oh-my-zsh projects give you.

Take tmux-sensible for example, https://github.com/tmux-plugins/tmux-sensible. Each configuration item is explained in detail.

So the goal here is to give new users a starting point that is well documented and explained, instead of finding joeschmo's dotfiles that has "set -g default-command "reattach-to-user-namespace -l $SHELL"" with no explanation on what that does.

I think vim-sensible is much less of an issue than oh-my-zsh.

Sensible isn't a whole mess of scripts and settings. It's 100 lines of highly readable vim settings and at the top there's a comment instructing people to use :help to learn more about what everything does.

I guess a case could be made for adding descriptive comments to make it more approachable for beginners, but it's not some black box of magic.

Learning everything from scratch is a big ask not everybody is willing to jump for. Some users might feel intimidated by the amount of things to learn before they can become productive.

If that gets new users in, make them comfortable until they outgrow the setup then it's a good thing.

You sound like average people should not start from Windows but from Slackware, so they will have better understanding of what's comprised of their machine.

It's a good start to give people the sense of what can be achieved by customization. If they don't like it from there they can certainly learn and tune to their needs, which should give more motivation than getting stuck googling for hours without any results from a bare terminal.

I have been coasting for nearly two decades from experience from running Slack.

You make a good point - starting from scratch requires too much effort to see any reward, but I think a simple, relatively stripped-down system is easier to understand and easier to build upon. A batteries-included setup can be an impediment to learning. When something is working, there is less motivation to learn how it works. After all, how many Windows users ever take a look behind the curtain?

From my perspective, a stripped-down system is like a set of wood blocks, and a batteries-included system is like a doll house.

If you give a child a doll house, the child could reverse-engineer the doll house to figure out how it was built, and to customise it, but the child will probably just play with it as-is, and focus on setting up doll furniture and re-enacting domestic life.

If you give the child wood blocks, the child will have to build a house for the dolls. The child will have to figure out how to make it structurally sound, how to make a gabled roof, how to make holes in a wall for windows, how to make a porch, etc. Of course, if they have never seen a doll house, it may never occur to them to build one, but they will probably build something. Later the child may progress to customising blocks, or making new blocks, or even full carpentry, building upon the earlier skill-set.

But, like you say, if you just give the child a felled tree, it is unlikely that they will figure out how to turn it into blocks, or into a doll house, or anything really. It's too big of a leap for them to make.

My experience with vim is that if you start with the default, it's probably too frustrating. Most plugins are essentially training-wheels: less efficient, but more intuitive means of carrying out basic tasks. For instance, 'easymotion' is far simpler than learning all the text objects and how to move around them, but it also requires another keypress and is less effective.

I think a lot of batteries-included stuff, at its best, is like that - stuff that you don't fundamentally need, but that puts a smoother corner on the rough and unshapely form of something that cares more about power than intuitiveness.

Good point, there's something to be said to try software in its default settings the way the developer(s) intended. However, there's also something to be said for optimisation. If you fire up a game, do you first configure the graphics and keybinds or do you go right away? Its up to you, the user.

I like your approach, but something can be said about an all-in-one solution as well.

Additionally, the website mentions:

> Install

> To install, run this command in your terminal:

> sh -c "$(wget -q https://raw.githubusercontent.com/aaronkjones/noobs-term/mas... -O -)"

> If you do not have wget use,

> sh -c "$(curl -fsSL https://raw.githubusercontent.com/aaronkjones/noobs-term/mas...

I smirked at the "if you do not have wget" cause whilst I was reading it I expected an alternative to executing the shell script, but no. What if I don't want to download a .sh script and execute it? Why teach "noobs" this behaviour?

I think this is good. At the end of the day, the best environment imho for building efficiently is the terminal, but it's slowly becoming a lost art. :/

While it looks great, for a real noob the real problem (at least when I was starting out this was mine) is fast terminal navigation. To learn to do that I always thought the normal progression is sort of like this:

1. Mastering getting around terminal with slight configuration (bash, zsh, random dotfiles, maybe a plugin manager)

2. Getting used to editing files in the terminal (Vim)

3. Managing multiple terminals at once (tmux)

Managing all of those changes at once kind of overloads you where it slows you down to much to really consider this a practical change at one once.

You have just about the same exact set up that I do as well barring a few minor differences, Nord theme included, which is pretty funny that they converged like that.

I've found that using a bookmarking system helps cut down the use of cd a lot. That's the latest addition I've made to my terminal setup, and it's helped a lot.

sounds useful. i cd often. can you expand on your bookmarking system?

One better, I can link you to it (I had written my own version at work, but ran across this and forked it to switch out the command names, since someone else had done it alreay)

https://github.com/yumaikas/bashmarks/blob/customized/README...

Developers will be doomed to reinvent bookmarking systems when all you really need to do is set CDPATH

Here's how to do it in ZSH:

https://robots.thoughtbot.com/cding-to-frequently-used-direc...

As an alternative, there's also fasd: https://github.com/clvv/fasd

This looks really well done. I've been meaning to do this for some time. While I agree it's best to learn to properly configure your tools, this can be a good first step for newbies.

The problem I run into with sharing dotfiles is that my dotfiles aren't what someone who's new should be using. They need sane defaults that they can build upon, not the mess that my dotfiles have become over 10 years. This seems to be a good solution to that problem; giving some nice basics to set a newbie on the right track.

Really well done.

Thank you. You summed up precisely my thinking. I think the “sensible” projects lay a foundation people can learn on. I just wrapped them up into a single package.

Not a noob but book marking for the cool library ideas.

It looks awesome but... tmux with "control + a" instead of the default "control + b"? That is horrible!

"control + a" moves you to the beginning of the line in bash (and in other shells, like zsh).

It works pretty well if you bind C-a to send C-a. It is easy to get used to pressing C-a twice for beginning of line, and if you do it outside tmux it is harmless.

As someone who use intensively Tmux, I find easier to not touch the default configuration. Press twice vs use something that works perfectly.

You are quite lucky, C-a could easily have been the default and then you would have to either use it or have a config ;-).

The disadvantage of C-b is that you need two hands to press it on a QWERTY keyboard, so I kind of wish I had picked C-x or something instead. But there is no consensus about what the default should be (lots of people use C-a, C-b, `, C-e, etc) so it is not worth changing now.

With C-b you have less movement, C-a moves your hand in a weird form which creates pain in the hand. Apart from that, I use only my left hand to press C-b.

C-a is the default one in Screen but as far as I remember C-b is the default one in Tmux since the beginning of the project.

C-x is a bad idea too, because is another shortcut in bash (C-x + e bring up the $EDITOR). I think C-b is a good choice.

The only thing I change in tmux is the pane and windows number (I prefer to start in 1 instead of 0 because I can type with less movement).

...not if you use vi style editing mode - which is awesome! :)

https://wiki.archlinux.org/index.php/readline#Editing_mode

I've installed this and now realised I only want a few of the apps installed. Is there an uninstall command?

The packages that get installed are: git curl wget zsh tmux neovim

It depends on what OS/platform you are using to uninstall a package.

The configuration files are in the ".dotfiles" directory of your home folder. You can remove one or all of them from there and restart your terminal.

Is `sh -c "$(wget $link -O -)"` supposed to be better than `wget $link -O - | sh`?

It's still executing code right from the internet without any checking. What it does fix is one of the ways in which a server can tell that a script is being executed and not just downloaded for reading: when piping, the download stalls while the shell is slugging through the script, but when it's done in a shell escape as here, it's downloaded in one go. So theoretically, you have less chance of reading something different (when inspecting the source) than what the shell is going to execute.

However, the script can't be overly long this way, since there is a limit to the command line length on Linux.

Safe, however, this is clearly still not.

By safe do you mean there is something insecure with redirecting output in this manner or do you mean one shouldn’t sh -c $(wget... without first checking the source of what they’re downloading?

*By unsafe

Mostly the second, you should check what you're downloading and executing. But a server can send two different files on two similar requests, ans perhaps it sends you a "good" file when you view it in your browser and a malicious file when downloading it via wget.

When piping, there is a well-known trick how the server can detect the difference even disregarding stings like the user agent header, but that trick doesn't work when you do $(wget ...). But I won't guarantee there isn't some other trick that can be performed.

TL;DR: someone's dotfiles. Neovim, tmux, and Oh My Zsh.

Pretty much, this.

My own dotfiles are installable with only a couple of commands - I just clone the repo and run a simple shell script that symlinks some things to a central location. The only thing that isn't included is the installation of binary dependencies (like neovim and its plugins), but that differs between OSes and didn't seem worthwhile to automate.

At least it's authored for new users to get started easily than a random guys dotfile git repo...

Has anyone else tried it?

Reply on news.ycombinator.com