These are some of the configurations and scripts that I use to make my life in Linux more functional and enjoyable.
- shell interpreter: zsh
- zsh plugin manager: zinit
- terminal emulator: alacritty
- desktop environment: gnome-shell
- text editor: nvim
- backup: arbie
- file browser: fzfx
- notes & tasks: journal
- time logger: timewarrior
A setup script link the dotfiles in this repo to those on $HOME.
Usage: ./setup <recipe>
Recipes on recipes/. Run from the project root.
The force mode, -f option, bypass the file already exists checks and auomatically remove any existing file. Don't use options as first argument.
I tried it originally but just didn't like the flow. Maybe doing things differently would improve it but I am happy with my current approach.
I followed the instructions by harfangk
git init --bare $HOME/.dotfiles`
echo 'alias g...="/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME"' >> $HOME/.aliases
g... config --local status.showUntrackedFiles notwpayne/chezmoi is interesting but I don't need those features right now or they are superseded by other tools that I currently use and so it would add unneeded complexity. That may change in the future though.
"If you do not personalize your configuration or only ever use a single operating system with a single account and none of your dotfiles contain secrets then you don't need chezmoi." — chezmoi README
Check:
Sometimes but not always. Those hacks save time put also took me a lot of time to discover, create, test and improve.
Some things might not work unless you have the same programs and versions that I'm currently using.
Some configs are personal and is a good idea to check before using. As an example I have my public PGP key set on Git config.
Zinit will not work unless you have priorly established a SSH handshake with Github due to SSH being forced over HTTPS on Git config.
Let's think of a common use case, editing files as superuser. There are many ways you can run a text editor as root and they all apparently do the same thing albeit being very different.
As it boils down to preserving environment variables I wrote, to demonstrate the different behaviour of these tools, a simple script that prints the variables $USER, $HOME and $VIMINIT. The later being a long string represented simply by yes/no bellow, meaning that it was passed along or not to the new shell.
| command | USER | HOME | VIMINIT |
|---|---|---|---|
| sudo | root | /root | no |
| sudo -E | root | /home/user | yes |
| su | user | /root | yes |
| sudo su | root | /root | no |
What basically happens is that sudo reset the environment variables while su just overwrite some of them.
su manpage:
For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing environments.
sudo manpage:
When sudo executes a command, the security policy specifies the execution environment for the command.
And that policy is to unset all variables unless Defaults env_reset in /etc/sudoers is changed to Defaults !env_reset. Despite I despising typing sudo before every command, it is indeed more robust and safer than su for use with desktop environments. At least by default.
"So what if you want to make vim or whatever else work with 'su'?"
First you have to link or copy your vim configuration to /root and if you use $VIMINIT you can't run sudo su. If you link the files you are increasing surface for root privilege escalation and copying the files, even if automated, is avoidable boring maintenance.
Also you would not want to have a vimrc over one 1K lines causing problems when things fall apart and you have to log in as root as last resort to restore the system.
"So what if I want to use 'sudo' for that."
You can use sudo -E to preserve environment or edit sudoers file for having it by default. But still, you will be increasing surface for root privilege escalation and mixing environments is bad practice and can cause tragic side effects. Sometimes it's not a good idea to run things in mixed environments, things may not work and user files may be overwritten as root.
The only 'sane' alternative is to use sudoedit or su -e which creates a temporary file for editing and overwrites the actual file with it when exiting. It uses the editor set at $SUDO_EDITOR, $VISUAL or $EDITOR, whichever comes first. Hacks are not desired here.