Wrapping xdg-open is the single greatest “that’s so simple, why didn’t I think of that?!” idea I’ve heard all month! Configuring xdg-open is incredibly annoying..
Agreed! I actually ended up wrapping both xdg-open and thunderbird in his suggested way, to block mailto: handlers globally in my environment. Another trick I used is to replace the execution of a blocked handler with exec notify-send "Blocked:" "$1", which will send an unobtrusive desktop notification in GNOME that the given handler was blocked. I think I will use this “shell wrapper in my $PATH” trick more often, now!
exec notify-send "Blocked:" "$1"
Wrapping thunderbird is also an amazing idea, I’m going to do that now! Thanks for sharing this!
I do the same thing, and even wrote a tool to help out with some stuff. Notably, it will merge your Git repository with $HOME by performing this command:
$ homer init https://github.com/your/dotfiles.git
In my own dotfiles repo (private), I have a bootstrap script that installs Homebrew and Homer, then runs this command and installs any packages I have set up in Brewfile.
There are also some commands for adding files, updating files from the remote, and using ZSH plugins from Antigen, as well as some sane conventions like an edit command for running your $EDITOR and a view command for viewing files with the $PAGER. It also establishes a directory named ~/etc/profile.d that can be used to store configuration executed when a new shell is launched, keeping your ~/.zshenv and ~/.zshrc clean.
exec qutebrowser "$1"
Cant xdg-open handle URLs?
I think xdg-open relies on some freedesktop.org “mime handler” configuration, and this hack allows him to not bother learning about all of that (or worrying about re-configuring it each time he updates his desktop environment). It’s basically saying for any HTTP/HTTPS URL or any .PDF file, open up his browser of choice, regardless of what xdg-open’s default mime handler configuration may be.
I do this too. I ran git init in my home folder at some point.
I have the star at the top of my gitignore, but I’ve also forced certain files to be tracked like this:
<and then like 12 more files or directories>
There are some downsides to having your home directory being a git repository; namely, my bash prompt, which shows git status, always defaults to my home directory if I’m not in a different repo. Every once in a while I end up running git commands on a directory that isn’t itself a git repository, so I end up accidentally performing that action on my home directory instead. Oops.
I did a git clean once too often on my home directory, so I decided to wrap git in a function that checks for the existence of a .git-noclean – if this file exists, then the clean command is ignored.
This is a cool idea. Is the exact wrapper published somewhere?
Nope, but here’s the function (in fish shell syntax):
# hub, also, put a belt-n-suspenders thing over our git-clean
# susceptible homedir
if test $argv = "clean"
set git_base (git rev-parse --show-toplevel)
set ignore_file $git_base/.git-noclean
if test -f $ignore_file
echo "JFB: cannot clean $git_base (ignore file exists)"
In case it’s helpful to anyone else: inspired by helpful crustaceans on another recent dotfiles post, and a mild aversion to flags named --force (and having a $HOME/.git folder), I have a pair of dead-simple fish aliases to manage exactly which dotfiles are tracked:
alias cfgit git --git-dir=$HOME/.config/cfgit --work-tree=$HOME`
for a in $argv;
echo (string replace -r "^$HOME" "" (readlink -f "$a")) >> $HOME/.config/cfgitignore
cfgit rm -r --cached "$a"
cfgit config core.excludesFile=.config/cfgitignore
This way cfgit is my config-file-specific git command (runnable from anywhere), and cfgignore allows me to track all files that I haven’t explicitly included or excluded.