Estratégia para manter dotfiles para diferentes SOs (ex. osx e ubuntu)

Question

Eu uso um repositório Git para manter meus dotfiles (vimrc, zshrc, tmux.conf, etc.). Como eu tenho dois sistemas operacionais diferentes (OSX em casa e Ubuntu no trabalho), eu dediquei uma ramificação para cada sistema. Isso resulta em diferentes versões de dotfiles, já que os SOs não são usados para usar as mesmas ferramentas / bibliotecas para fazer um trabalho. Isso faz com que a manutenção de arquivos de pontos seja difícil para todas as ramificações (dotfiles divergentes). Eu estava pensando se poderia haver uma estratégia melhor para isso. Talvez incluir arquivos pontuais específicos do sistema em outro arquivo e incluí-los em arquivos de pontos.

Em outras palavras, estou procurando uma estratégia de plataforma cruzada para a manutenção de dotfiles para computadores com sistemas operacionais diferentes.

Agradecemos antecipadamente por qualquer ajuda

    

Answer 1

Para scripts de shell como o .zshrc você pode usar uma variável de ambiente ou a resposta a algum comando como uname. Mas, para arquivos pontuáveis que não sejam shell, como .vimrc, você deve fazer o trabalho manual de enviar correções de um ramo para outro (de um SO para outro).

    

Answer 2

Além da resposta da Envite: eu uso um arquivo comum .zshrc , onde todas as coisas "portáteis" (como as definições das funções do shell, etc.) estão incluídas. Além disso, tenho um arquivo extra .zshrc-MACHINE_A etc. para cada computador em que estou usando a configuração compartilhada. Aqui eu defino, e. o PATH , algum alias refletindo os atuais programas instalados e assim por diante.

A última parte do meu arquivo comum .zshrc é exibida

# load $HOST specific setting

if [[ -f ~/.zshrc-$HOST ]]; then
   [[ ! -f ~/.zshrc-$HOST.zwc || ~/.zshrc-$HOST -nt ~/.zshrc-$HOST.zwc ]] && { zcompile ~/.zshrc-$HOST; print - compiled \~/.zshrc-$HOST. }
   source ~/.zshrc-$HOST
fi

De acordo com man zshparam , o parâmetro $HOST contém o nome do host atual, portanto, deve ser portável e salvar uma chamada de programa externa. E toda vez que o arquivo .zshrc-$HOST for alterado, ele será compilado (via zcompile ). A compilação serve ao propósito de (cito man zshbuiltins ):

(...) faster autoloading of functions and execution of scripts by avoiding parsing of the text when the files are read.

Provavelmente hoje em dia você não notará nenhuma diferença (?), mas também não vai doer. Btw. os arquivos compilar *.zwc são dependentes da arquitetura e não podem ser trocas entre diferentes sistemas.

    

Answer 3

Minha solução é ter repositórios separados para cada máquina.

Como o git não segue links simbólicos (apenas os armazena) e hard links não funcionam , eu escrevi um script que contém uma lista de arquivos que são os mesmos em ambas as máquinas. Depois que eu fiz alterações em um dos repositórios, eu corro o script.

Se detectar (minha computação em uma soma de verificação) que qualquer um dos arquivos compartilhados foi alterado neste repositório, ele os copia para o outro repositório. Então eu mudo para esse repositório e confirmo que as mudanças estão bem.

    

Answer 4

Aqui está a melhor solução que encontrei . Eu recomendo clicar no link em vez de ler sobre isso aqui:

THE IDEA

I've adapted @holman's ideia of symlinking files whose filename ends with ".symlink", and instead I'm symlinking files whose filename matches the regular expression \.(<os>-)?symlink$. By doing that, I can have files that are always symlinked, and files that are symlinked just in a specific environment.

For example, in my ~/.gitconfig I include ~/.gitconfig_include, which contains OS-specific configurations.

[include]
    path = ~/.gitconfig_include

Then I have two .gitconfig_include files: one for Linux and another one for Windows.

dotfiles
|-- git
    |-- .gitconfig.symlink
    |-- .gitconfig_include.linux-symlink
    |-- .gitconfig_include.windows-symlink

This allows a symlink to have the same name, but different targets, depending on the OS.

Unfortunatelly, this strategy wasn't enough to handle all the requirements for my cross-platform dotfiles.

Vim's bad decision on Windows

For some reason, Vim looks for its files in ~/vimfiles instead of ~/.vim on Windows. This means that, if I wanted to maintain the same strategy, I would have to duplicate the files folder—which I didn't want to do, for obvious reasons.

dotfiles
|-- vim
    |-- .vim.linux-symlink
    |-- vimfiles.windows-symlink

Instead of duplicating the files folder, I've created a file matching the folder's name, with the ".symlinks" extension.

dotfiles
|-- vim
    |-- .vim
    |-- .vim.symlinks

The .vim.symlinks file contains the symlink name for each environment.

linux: .vim
windows: vimfiles

This allows a symlink to have different names, but the same target, depending on the OS.

THE WORKING SOLUTION

If you want to check how everything ended up, please visit my dotfiles on GitHub.