fish, the friendly interactive shell, is a commandline shell intended to be interactive and user-friendly.
fish is intentionally not fully POSIX compliant, it aims at addressing POSIX inconsistencies (as perceived by the creators) with a simplified or a different syntax. This means that even simple POSIX compliant scripts may require some significant adaptation or even full rewriting to run with fish.
Shell configs are hard to move. Some in $HOME/.config , some in .[idk]rc files, etc.
It’s messy. Unless you write everything you modify. If you did not do that up to now…good luck moving shell configs.
What? No they aren’t hard to move. They’re usually just one file. Copy to your new machine and done.
I have no shell configs of any kind because it seemed like everytime I used another computer, I would not have them and I would end up having the re-learn everything.
So instead I google every command every time or ask chatgpt, like this
I find it very annoying there’s isn’t a reliable way to use alias or shells, functions and stuff.
What I do is store my dotfiles in a git repository, and leave symlinks to the files in that repository. Then, when I move to another computer, pulling over all my configuration consists of doing a
git pullto pull the git repo over and then running a command to set up the symlinks on that new computer. I can also make changes and selectively push things in. Some things need to be specific to a computer, and those don’t go in.I use a homebrew script to set up the symlinks. A number of people use GNU stow for this.
kagis for an example of someone using stow
https://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html?round=two
If you edit the symlinks in emacs (and I imagine vim), it picks up on the fact that they’re symlinks into a git repository and that they’re version-controlled.
So, like:
Have a bare git repository on home machine, the “master” copy.
Every machine with an account has a non-bare dotfiles git repository checked out and symlinks pointing into that repo.
Make any changes on a given machine like you normally would, then git commit them to the local non-bare dotfiles git repo and push them to the master repository.
If setting up on a new machine, pull the git repository, and then run the command to set up the symlinks.___
That does sound like a good plan and I do have my own git server but
Can I expect to be able to do this in the various work shells I come across ?
Or do I risk becoming afoul of IT security ?(especially as it is not practical to ask each of them)
I mean, that’s not a question I can answer for you. I have never had a problem, myself, but I have no idea what your professional situation is. There are a shit-ton of ways to move git repositories around. If you can ssh out, if you can move physical storage in and out, if you have https out (though that’ll be unidirectional in). I doubt that a typical IT department is going to care about you moving your dotfiles in, so if they do block something, probably worth a try just saying “I just want to pull my dotfiles from home; what’s a good way to do that?” My guess is that most IT departments aren’t going to have an issue with that. If you work for an intelligence service or something that has really super-stringent security requirements, then having any data movement in or out may be more of a headache.
I would be careful to avoid sticking credentials (keys, passwords, anything like that) in any git-managed dotfiles. Not an issue for most software, but there are a few packages that will do that (
neonmodem, a BBS-themed console Linux Lemmy client, does that…was just trying it yesterday.) You don’t want to be dumping your home credentials all over in your git history, and work isn’t going to want you pushing work credentials out.