[godelski]

Literally anywhere else! Your dotfiles should be publishable to github. If they aren't you're doing them wrong.

A good thing to do is organize. You can actually load different files. Here's a pretty common pattern that you'll find and it'll illustrate how to do other things

  if [[ $(uname) == "Darwin" ]]; then
      source "${INSERT_SOME_DIR}/osx.zsh"
  elif [[ $(uname) == "Linux" ]]; then
      source "${INSERT_SOME_DIR}/linux.zsh"
  fi

You do this for loading based on the operating system. You might want some aliases, commands, or other routines in one but not the other. For example, in my linux one I have stuff for cuda paths. You can do all sorts of things too, like make a (generically named) work file, which you don't publish to github but you load it if it exists. Then you can put all your work related aliases there and not contaminate anything else. Something like `[[ -a ${INSERT_SOME_DIR}/work.zsh ]] && source ${INSERT_SOME_DIR}/work.zsh`.

You shouldn't really load secure keys this way, but others had good answers so I thought I'd at least share a more general pattern since it isn't as well known among the less terminally inclined.

[analog_daddy]

Okay. Here is a pattern i follow everywhere in my init files for almost every program. Define two key env vars. $DOTFILES and $ECORP. The first is path to your personal set of dotfiles. The second is path to your corporate specific dotfiles.

On personal pc no need to define the $ECORP var in shell init. On work pc define that var.

based alone on that you can conditionally do almost anything.

- shell source files/aliases

- vim/editors enable disable plugins based on existence of env vars.

- define shortcuts in file manager.

- and i add the following to my main $DOTFILES .gitignore.

  # Any file that contains the following will be ignored.
  # Used to ignore files in corporate environment
  *ECORP*
  *ecorp*

Based on multiple years across different setups, using environment variables was the most reliable option since I have been in places where there are restrictions on where my init files can be placed and having to change a shit ton of paths in my dotfiles or just keeping a different branch for work and personal (and making sure they stay in sync) was too much of a hassle.

Additionally, maintaining hygiene is essential, where I only use a Read Only PAT token on my personal dotfiles in workenv. That way, there is no accidental way I would be able to push from my workenv.

[hk__2]

You’re just splitting your dotfiles into a public and a private part. That’s useful if you want to publish the public part on GitHub, but not everyone wants to do this, and the issue of storing secrets in plain text files remain.

[godelski]

  > You’re just splitting your dotfiles

Ummm... yes? That is what I said

  > the issue of storing secrets in plain text files remain.

Ummm... kinda? The problem was that reading an rc file was considered dangerous. Not putting keys in your rc files is an improvement. Encrypting them is even better than that. But I also said more words in the original post and you don't really even need to read between the lines to figure out I said "you can generalize this", especially when there's comments next to it saying "here's how you load an encrypted file"