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.
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.
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 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?
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.
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.
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.
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)
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.
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.
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.
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).
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.
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?
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.
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.
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.