4 ms·

Personally I'd recommend not customising your shell and just learning to live with the defaults on whatever operating systems you tend to use. Makes it much qui

Personally I'd recommend not customising your shell and just learning to live with the defaults on whatever operating systems you tend to use. Makes it much quicker to be comfortable on a new machine because everything is already same as you're used to.

castis 7y ago
On the other hand I'd recommend customizing as much as reasonably possible on your home rig. You stand to learn so much more about how your system is constructed. Once you get to a certain level of understanding, most machines that you come into contact with that sport a terminal are easily usable.
- RMPR 7y ago
  Not without a learning curve, depending on the level of customization we are talking about.
  - castis 7y ago
    Well sure, the learning curve is the fun part!
wincent 7y ago
Or you could stick your dotfiles and other config in a repo and clone it onto the new machine. Some examples of approaches on this prior thread: https://news.ycombinator.com/item?id=11070797 https://news.ycombinator.com/item?id=11070797
- RMPR 7y ago
  GNU Stow[1] and chezmoi[2] are two decent approaches for solving common dotfiles problems. [1]: https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/ [2]: https://fedoramagazine.org/take-back-your-dotfiles-with-chezmoi/ https://fedoramagazine.org/take-back-your-dotfiles-with-chez...
- emilecantin 7y ago
  I went a step further, and automated as much as I can with Ansible. Had to reinstall everything after an SSD failure recently, this made it a fun project. I'm also planning on upgrading my machine soon, so that should make the process a lot faster. I started from this and customized it to my needs: https://github.com/geerlingguy/mac-dev-playbook https://github.com/geerlingguy/mac-dev-playbook
trm42 7y ago
I would go with some middle ground. I have my bash and git aliases etc for fast local work (which speeds up my normal work), but I have nothing so complicated I couldn't live without them on a random remote server. I would like to start using zsh but that would introduce too much of variation from the remote envs I might encounter.
- RMPR 7y ago
  I second this, a little customization as close as possible to the default experience.
  - pletnes 7y ago
    I third this. And push your most convenient aliases and git hooks or whatever to github. It’s not much work to symlink, git clone, ansible them, or whatever works for you.
RMPR 7y ago
> I'd recommend not customising your shell and just learning to live with the defaults Sometimes the defaults are not sane at all, for example urxvt, it's just a blank window with a very small font size, I'd advise to customize, but not heavily so that in a matter of seconds (the time to copy your config file) you can have the thing you're used to.
geocar 7y ago
I've been basically "using the defaults" for the last ten years after spending twenty years customising everything; I've noticed a couple other good advantages: - It's easier to understand what your customers will see: If they customise things, they'll need to figure those things out themselves anyway, but if you customise things, there's a chance you'll forget a detail and it'll leak out to your users. - Nudge; Your automation tends to spread: If I have a deploy_to_prod alias, chances are it can only be used by me, but if my project has a deploy.sh script, then there's a path to get other people on my team to use it. If you've got the discipline for this by some other way, then that's great, but having to eat dog food meant I first had to make the dog food, and requiring (of myself) helped me build that habit. - It's one less thing to think about. Of course, the downside is that one day I woke up and found myself using zsh.
migueloller 7y ago
This is addressed in the first paragraph of the article. > "I feel that sharing files between different computers is now a solved issue, and the benefits I get from having personalized my work environments are so great that I gladly pay the small price of synchronizing that configuration between my computers."
- RMPR 7y ago
  Depends on the level of customization we are talking about though, sometimes it's way more than just a few configuration files.
- Majestic121 7y ago
  The issue is not solved when you sh into a container for a quick debugging session. Or when you work in an airtight environment, like in banking. It is 'solved' when the only computers you connect to is small enough to be be described as 'my computers', which seems like a pretty narrow use case to me.
tryptophan 7y ago
This is why I like fish shell so much. It has the same features as zsh, but requires no config. They have a guiding principle of "if users need to configure something, that means that the defaults are broken". All I do is "sudo apt install fish" and I'm good to go with the 100s of out-of-the-box improvements it has over bash.
- RHSeeger 7y ago
  Honestly, this sounds bizarre to me. The idea that everyone likes the same things in a shell makes no sense to me. I like a 2 line prompt (where am I, what context am I in). A lot of people don't like this at all.
  - SAI_Peregrinus 7y ago
    It's not that config is impossible, but it tries very hard to make the defaults work for the largest subset of users possible. And then provides a much easier config experience than most shells, since if things are broken for you they should damn well be easy to fix!
jeandejean 7y ago
It's not necessarily exclusive, you can be used to default settings when connecting to containers or remote servers, but still have your own local customization.
robenkleene 7y ago
I understand the reasoning behind this, but in practice I can't imagine working like that. I love watching Gary Bernhardt (https://www.destroyallsoftware.com/screencasts https://www.destroyallsoftware.com/screencasts), who is an incredibly fast typist and knows Unix very well. But I just can't get over the sheer volume of typing he does, because he hasn't wrapped his most common commands into short aliases and abbreviations[0]. I would find it exhausting to do that much typing relative to the amount of output. Here's a customization I would recommend everyone who spends a lot of time on the shell do: Be able to fuzzy find from the shell. The specifics aren't important, but here's how my bindings work (I use and recommend `fzf`[1] for this): - `⌥z`: Fuzzy find recent directory (using `fasd`[2]) - `⌥c`: Fuzzy find recursive subdirectory - `⌥e`: Fuzzy find recursive file All of these work logically like this: If the binding is triggered at the start of a prompt, do what I mean (`cd` to directories, or edit a file), but if I've already typed something, insert it as a parameter, so for example I can hit `ls<space>⌥z` to fuzzy insert a recent directory (or just `⌥z` at a raw prompt to fuzzy select a recent directory to jump to). I'd argue fuzzy finding is the major enhancement to computer productivity of the last twenty years. I recommend using it on the shell (assuming you use the shell often enough to justify it). [0]: https://fishshell.com/docs/current/cmds/abbr.html https://fishshell.com/docs/current/cmds/abbr.html [1]: https://github.com/junegunn/fzf https://github.com/junegunn/fzf [2]: https://github.com/clvv/fasd https://github.com/clvv/fasd
- SAI_Peregrinus 7y ago
  > But I just can't get over the sheer volume of typing he does, because he hasn't wrapped his most common commands into short aliases and abbreviations[0]. Interestingly I go the other way: I type fast, so I don't need to abbreviate. Instead I make my aliases and abbreviations memorable. EG for git instead of aliasing `checkout -b` to `cb` or something I alias it to `newbranch`. More typing than the two-character alias, but also more memorable than the default. I find if a command isn't memorable I'll forget to use it, so I never build the habit needed to make it useful. Single-letter commands are especially bad for this. I've had z for years, and remembered to use it when I needed it maybe once. Also +1 to fish and fzf, both are great.
  - 7y ago
SAI_Peregrinus 7y ago
Or customize, keep the relevant bits in git, make a shell script to install any utilities you add, and push the whole thing to whatever hosting provider you want. Then you can get comfortable with the new machine by checking out your remote and running the one script.
- RMPR 7y ago
  Laughing in an airtight environment

castis 7y ago

On the other hand I'd recommend customizing as much as reasonably possible on your home rig. You stand to learn so much more about how your system is constructed. Once you get to a certain level of understanding, most machines that you come into contact with that sport a terminal are easily usable.

RMPR 7y ago
Not without a learning curve, depending on the level of customization we are talking about.
- castis 7y ago
  Well sure, the learning curve is the fun part!

wincent 7y ago

Or you could stick your dotfiles and other config in a repo and clone it onto the new machine. Some examples of approaches on this prior thread: https://news.ycombinator.com/item?id=11070797 https://news.ycombinator.com/item?id=11070797

RMPR 7y ago
GNU Stow[1] and chezmoi[2] are two decent approaches for solving common dotfiles problems. [1]: https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/ [2]: https://fedoramagazine.org/take-back-your-dotfiles-with-chezmoi/ https://fedoramagazine.org/take-back-your-dotfiles-with-chez...
emilecantin 7y ago
I went a step further, and automated as much as I can with Ansible. Had to reinstall everything after an SSD failure recently, this made it a fun project. I'm also planning on upgrading my machine soon, so that should make the process a lot faster. I started from this and customized it to my needs: https://github.com/geerlingguy/mac-dev-playbook https://github.com/geerlingguy/mac-dev-playbook

trm42 7y ago

I would go with some middle ground. I have my bash and git aliases etc for fast local work (which speeds up my normal work), but I have nothing so complicated I couldn't live without them on a random remote server. I would like to start using zsh but that would introduce too much of variation from the remote envs I might encounter.

RMPR 7y ago
I second this, a little customization as close as possible to the default experience.
- pletnes 7y ago
  I third this. And push your most convenient aliases and git hooks or whatever to github. It’s not much work to symlink, git clone, ansible them, or whatever works for you.

RMPR 7y ago

> I'd recommend not customising your shell and just learning to live with the defaults Sometimes the defaults are not sane at all, for example urxvt, it's just a blank window with a very small font size, I'd advise to customize, but not heavily so that in a matter of seconds (the time to copy your config file) you can have the thing you're used to.

geocar 7y ago

I've been basically "using the defaults" for the last ten years after spending twenty years customising everything; I've noticed a couple other good advantages: - It's easier to understand what your customers will see: If they customise things, they'll need to figure those things out themselves anyway, but if you customise things, there's a chance you'll forget a detail and it'll leak out to your users. - Nudge; Your automation tends to spread: If I have a deploy_to_prod alias, chances are it can only be used by me, but if my project has a deploy.sh script, then there's a path to get other people on my team to use it. If you've got the discipline for this by some other way, then that's great, but having to eat dog food meant I first had to make the dog food, and requiring (of myself) helped me build that habit. - It's one less thing to think about. Of course, the downside is that one day I woke up and found myself using zsh.

migueloller 7y ago

This is addressed in the first paragraph of the article. > "I feel that sharing files between different computers is now a solved issue, and the benefits I get from having personalized my work environments are so great that I gladly pay the small price of synchronizing that configuration between my computers."

RMPR 7y ago
Depends on the level of customization we are talking about though, sometimes it's way more than just a few configuration files.
Majestic121 7y ago
The issue is not solved when you sh into a container for a quick debugging session. Or when you work in an airtight environment, like in banking. It is 'solved' when the only computers you connect to is small enough to be be described as 'my computers', which seems like a pretty narrow use case to me.

tryptophan 7y ago

This is why I like fish shell so much. It has the same features as zsh, but requires no config. They have a guiding principle of "if users need to configure something, that means that the defaults are broken". All I do is "sudo apt install fish" and I'm good to go with the 100s of out-of-the-box improvements it has over bash.

RHSeeger 7y ago
Honestly, this sounds bizarre to me. The idea that everyone likes the same things in a shell makes no sense to me. I like a 2 line prompt (where am I, what context am I in). A lot of people don't like this at all.
- SAI_Peregrinus 7y ago
  It's not that config is impossible, but it tries very hard to make the defaults work for the largest subset of users possible. And then provides a much easier config experience than most shells, since if things are broken for you they should damn well be easy to fix!

jeandejean 7y ago

It's not necessarily exclusive, you can be used to default settings when connecting to containers or remote servers, but still have your own local customization.

robenkleene 7y ago

I understand the reasoning behind this, but in practice I can't imagine working like that. I love watching Gary Bernhardt (https://www.destroyallsoftware.com/screencasts https://www.destroyallsoftware.com/screencasts), who is an incredibly fast typist and knows Unix very well. But I just can't get over the sheer volume of typing he does, because he hasn't wrapped his most common commands into short aliases and abbreviations[0]. I would find it exhausting to do that much typing relative to the amount of output. Here's a customization I would recommend everyone who spends a lot of time on the shell do: Be able to fuzzy find from the shell. The specifics aren't important, but here's how my bindings work (I use and recommend `fzf`[1] for this): - `⌥z`: Fuzzy find recent directory (using `fasd`[2]) - `⌥c`: Fuzzy find recursive subdirectory - `⌥e`: Fuzzy find recursive file All of these work logically like this: If the binding is triggered at the start of a prompt, do what I mean (`cd` to directories, or edit a file), but if I've already typed something, insert it as a parameter, so for example I can hit `ls<space>⌥z` to fuzzy insert a recent directory (or just `⌥z` at a raw prompt to fuzzy select a recent directory to jump to). I'd argue fuzzy finding is the major enhancement to computer productivity of the last twenty years. I recommend using it on the shell (assuming you use the shell often enough to justify it). [0]: https://fishshell.com/docs/current/cmds/abbr.html https://fishshell.com/docs/current/cmds/abbr.html [1]: https://github.com/junegunn/fzf https://github.com/junegunn/fzf [2]: https://github.com/clvv/fasd https://github.com/clvv/fasd

SAI_Peregrinus 7y ago
> But I just can't get over the sheer volume of typing he does, because he hasn't wrapped his most common commands into short aliases and abbreviations[0]. Interestingly I go the other way: I type fast, so I don't need to abbreviate. Instead I make my aliases and abbreviations memorable. EG for git instead of aliasing `checkout -b` to `cb` or something I alias it to `newbranch`. More typing than the two-character alias, but also more memorable than the default. I find if a command isn't memorable I'll forget to use it, so I never build the habit needed to make it useful. Single-letter commands are especially bad for this. I've had z for years, and remembered to use it when I needed it maybe once. Also +1 to fish and fzf, both are great.
- 7y ago

SAI_Peregrinus 7y ago

Or customize, keep the relevant bits in git, make a shell script to install any utilities you add, and push the whole thing to whatever hosting provider you want. Then you can get comfortable with the new machine by checking out your remote and running the one script.

RMPR 7y ago
Laughing in an airtight environment