Prezto: maneira fácil de personalizar o prezto

Há muito espaço para configurar o prezto nos arquivos já fornecidos para inicialização, é apenas uma questão de colocar suas substituições no local apropriado. a maioria deles provavelmente deve entrar em ${ZDOTDIR:-$HOME}/.zshrc antes de invocar o zprezto init, para escolher os módulos que devem ser carregados, usando as chamadas zstyle apropriadas (que reconhecidamente, são escassamente documentadas). então aqui está minha tentativa de tornar a documentação um pouco melhor. (Também estou enviando um PR com esta explicação, espero que a equipe ache útil)

(Para nossos novos usuários, a notação ${ZDOTDIR:$HOME} significa que se a variável $ZDOTDIR não estiver definida, ela deve ser o valor padrão de $HOME . é como um curto-circuito para uma instrução IF testando se uma variável está definida. Assim, source ${ZDOTDIR:-$HOME}/.zshenv é equivalente a:

if [[ -n $ZDOTDIR ]]; then
   DOTFILES_PATH=$ZDOTDIR
else
  DOTFILES_PATH=$HOME
fi
source $DOTFILES_PATH/.zshenv

#pro tip! set $ZDOTDIR on /etc/zshenv to ~/.zconf to have all runcoms live there instead of cluttering ~ =)

Além disso, qualquer ajuste no comportamento do prezto deve ser feito após invocar zprezto init em zshrc ou, em ${ZDOTDIR:-$HOME}/.zlogin . Observe, no entanto, que os arquivos zlogin (sysem ou usuário) serão originados apenas para shells de login . Isso significa que, ao fazer login em um sistema remoto via ssh, por exemplo, ou ao chamar, digamos, XTerm ou seu emulador favorito, especificando que você deseja um shell de login (chamando zsh -ls vez de zsh simples zlogin serão ignorados.

Além disso, observe que outra diferença entre shells de login interativos e shells interativos simples é que, além de fornecer arquivos zlogin , os shells de login interativos também alocam um pseudo-tty no kernel e são líderes de sessão. (os programas que você executa a partir dessa sessão serão subprocessos do líder da sessão. Além disso, se por algum motivo você matar o líder da sessão, seus filhos morrerão com ele ou se tornarão _zumbis_ ) para a mesma máquina que pode ter pseudo-TTYs limitados disponíveis. esse tipo de carga de trabalho costumava ser mais comum. (hoje em dia a maioria dos sistemas Linux são multiusuário, mas de operador único)

#Pro tip: configure your window manager to call zsh -ls for terminals. 
#Example using i3wm on ubuntu:

#i3wm.conf:
...
set $XTERM_CMD='xterm -e zsh -ls`
bind $mod+x $XTERM_CMD
...

Por que é que? porque os shells de login são considerados o principal ponto de interação com um usuário possivelmente humano (a verdade está aí), enquanto os shells sem login seriam gerados como _sub-shells_ de um shell de login , ao executar scripts que chamam zsh como um interpretador de comandos, por exemplo, quando o shebang é #!/usr/bin/env zsh ou equivalente.

Ao iniciar um novo terminal em uma sessão X11 , é seguro assumir que você já está interativo sem login . Ou seja, _por especificação_ o comportamento correto, mas não o comportamento que a maioria dos usuários espera .

Há uma razão para esse comportamento _especificado_: os arquivos zlogin devem ser usados ​​para configurações orientadas à tmux e a maioria dos alias es.

A vantagem de agrupar todas as configurações orientadas à interação em .zlogin é que shells não interativos (executando scripts via zsh -c [script] , o shebang , subshells ou shells invocados por make , por exemplo) não ser sobrecarregado por configurações adicionais, tornando-os mais rápidos e responsivos, pois _keybindings_ e _aliases_ nem são carregados na inicialização, afinal, um _script executável não interativo_, nunca deve chamar atalhos de teclado ou aliases (supondo que eles foram escritos corretamente para serem portátil)

Por fim, é uma fonte comum de frustração entre os usuários de ambientes gráficos, gastar algum tempo adicionando suas personalizações a .zlogin apenas para vê-las ignoradas ao lançar um novo XTerm ou tmux painel.

Isso pode ser resolvido chamando (ou aliasing) seu emulador de terminal com a opção necessária para invocar um shell de login , para XTerm , por exemplo, você chamaria xterm -e zsh -ls no tmux, você pode adicionar um dos seguintes linhas para o seu .tmux.conf :

        set -g default-command 'exec /usr/bin/zsh -ls' #this will make zsh a login shell AND a session leader
        set -g default-shell '/usr/bin/zsh -ls'

se você quiser substituir seu shell sem login em seu emulador por um novo shell de login brilhante, você pode emitir exec zsh -ls no seu prompt de comando. Fazer isso, no entanto , não gravará o INC_APPEND_HISTORY sido definido quando você iniciou o shell

INC_APPEND_HISTORY faz zsh anexar entradas de histórico assim que o comando for concluído. zprezto útil define INC_APPEND_HISTORY , INC_APPEND_HISTORY_TIME e SHARE_HISTORY que disponibiliza seu histórico imediatamente a partir de diferentes terminais na conclusão do comando e registra o tempo de execução no arquivo de histórico. Bem legal, hein?)

O erro oposto é aplicar todas as personalizações interativas em zshrc que leva a shells inchados em ambientes não interativos. Talvez os usuários de estações de trabalho desktop não notem nenhuma diferença, mas em ambientes com recursos limitados pode ser significativo em termos de tempo de execução e consumo de energia (v.gr ao executar um Raspberry PI com baterias ou em um ambiente de telefone celular como termux )

aqui está um resumo do arquivo de inicialização e sua finalidade, bem como quando eles são executados:

| sempre corre | quando GLOBAL_RCS é definido | quando RCS é definido | Propósito |coisas que geralmente vão lá, e notas |
|----------------|--------------------------|----- ------------------------|---------|----------- -------------------------------|
| /etc/zshenv | | | sistema fornecido ambiente mínimo | Sempre corre! deve ser um conjunto mínimo ZDOTDIR, ambiente mínimo. caminhos do sistema
| | | ${ZDOTDIR:-$HOME}/.zshenv | o ambiente do usuário substitui shells não interativos e sem login (quando invocado via shebang em um script ou via zsh -c [script] ou quando invocado por make | substituições de ambiente pessoal, como MANPATH , TERM , fpath scripts não interativos devem ter seu ambiente completamente configurado aqui )
| | /etc/zshprofile | | perfil do sistema para shells de login ( zsh -ls zsh - or via _ssh forced command_ )| caminhos mínimos do sistema para interação remota, site fpath , site $LOCALE , lang.
| | | ${ZDOTDIR:-$HOME}/.zshprofile | preferências pessoais para shells de login interativos | seus preferidos $LOCALE , $LANG , readlne config, cdpath , gerenciadores de sessão, fpath ) shells de login (mas não necessariamente inativos como quando invocado via _ssh remote cmd_ ) lerá a configuração até este ponto
| | /etc/zshrc | | script de inicialização fornecido pelo sistema, para shells interativos (shells locais que vivem em um XTerm , URxvt , gnome-terminal ) ou subshells (como executar xterm do prompt de comando de um _login xterm_, | contabilidade de login do site, monitores de segurança, política de log de comando do site
| | | ${ZDOTDIR:-$HOME}/.zshrc | customização pelo usuário de seu ambiente interativo para terminais | fornecimento de conclusões personalizadas ( gcloud.comp.inc ), estruturas de usuário personalizadas (zprezto é invocado aqui), caminho adicional exigido pelo software personalizado instalado em /opt/*
| | /etc/zshlogin | | personalização adicional para shells de login interativos, como aqueles acessados ​​via ssh | tmux anexar à sessão existente
| | | ${ZDOTDIR:-$HOME}/.zshlogin | script de usuário para inicialização do shell de login (este shell é um líder de sessão e aloca ptty |aliases, atalhos de teclado, programas de inicialização pessoais, aplicativos de rastreamento de tempo, gerenciadores de sessão, cotação do dia, fortunas
|.. | ... sua sessão de shell acontece aqui... |
| | | ${ZDOTDIR:-$HOME}/.zshlogout | tarefas de limpeza pessoal | definindo tarefas pessoais crontabs ou at , registrando checout no seu software de rastreamento de tempo, sorte para dizer adeus.
| /etc/zshlogout | | | tarefas de limpeza do site | parada da política de log de comando do site, registros de contabilidade de login, spindown do contexto de segurança, etc.

você pode estar pensando... por que zpreztorc não é invocado em .zlogin vez de .zshrc ? Acredito que foi uma compensação para eliminar a complexidade tendo todo o prezto configurado e lançado a partir de um único ponto, já que alguns dos módulos precisam ser adquiridos no início do processo de inicialização, editor e gnu-utls vem à mente. se invocado mais tarde na inicialização, como seria o caso em .zlogin tornaria mais fácil entrar em conflito com coisas que os usuários podem adicionar em zshrc . Além disso, evita *não ser carregado e causar frustração ao usuário se o usuário iniciar shells sem login a partir de ambientes gráficos, conforme discutido acima.

TL;DR

use seu .zshrc após o zprezto ser invocado ou antes para remover ou ativar pacotes por meio de chamadas zstyle

ou

use .zshlogin para substituir ou ajustar o comportamento do zprezto. há também .zpreztorc mas você pode querer deixar isso em paz.

De qualquer forma, essa questão é frequentemente levantada por usuários que usam os runcoms distribuídos como estão, o que é uma péssima ideia, já que fazer git pull para atualizar sua distribuição prejudicará suas personalizações. é uma ideia melhor copiar os runcoms distribuídos para seu $ZDOTDIR e mesclar quaisquer alterações que uma atualização possa trazer, se houver (elas geralmente são limitadas a .zpreztorc )

Esqueci de mencionar que, por padrão, no estoque zsh tanto RCS quanto GLOBAL_RCS estão prontos para uso, então a sequência acima é o que você normalmente esperaria uma nova instalação.

Pessoalmente, acho que as distribuições Linux derivadas do debian configuram um monte de coisas desnecessárias e indiretas (ei, sou um cara simples do BSD desde a puberdade). Algumas delas são boas, como os fpath aos diretórios de funções do site que adicionam complementos e complementos de menu a quase todos os comandos que você pode criar.

Então curta o absurdo copiando as coisas boas de /etc/zsh/zshrc para o meu ~/.zshrc e então
desativando GLOBAL_RCS no final do meu ~/.zshenv que tem o efeito de pular o sistema /etc/zsh/{zprofile,zshrc,zlogin} e apenas fornecer ${ZDOTDIR:-$HOME}/{.zprofile,.zshrc,.zlogin} nessa ordem.

eu não recomendo isso a menos que você realmente saiba o que está fazendo, você pode acabar com uma configuração inutilizável.

De qualquer forma, esta questão é frequentemente levantada por usuários que usam o _runcoms_ distribuído como está, o que é uma péssima ideia, já que fazer git pull para atualizar sua distribuição irá atrapalhar suas personalizações. é uma ideia melhor _copiar_ os _runcoms_ distribuídos para o seu $ZDOTDIR e mesclar quaisquer alterações que uma atualização possa trazer, se houver (elas geralmente são limitadas a .zpreztorc )

Se eu entendi o processo de atualização corretamente, devo fazer um fork deste projeto e lidar com conflitos de mesclagem toda vez que atualizar?? Isso é insano!

Depois de definir minha configuração, espero que as atualizações funcionem como em todos os outros programas.

Por que os runcoms não podem fazer suas coisas e, em seguida, obter arquivos locais como $ZDOTDIR/.zshrc_local ?
Esses arquivos locais devem poder substituir tudo. Talvez o prezto deva apenas marcar os módulos para inclusão até que o último arquivo de configuração seja carregado e finalizado e, em seguida, inclua tudo. Dessa forma, posso ter por padrão zprezto.rc algo assim:

zstyle ':prezto:load' pmodule \
  'environment' \
  'terminal' \
  'editor' \
  'history' \
  'directory' \
  'spectrum' \
  'utility' \
  'completion' \
  'prompt' \
  'git' \
  'ruby' \
  'rails' \
  'syntax-highlighting'

E no meu .zshrc_local eu poderia ter

zstyle ':prezto:unload' pmodule \
  'spectrum' 

Porque zstyle ':prezto:load' está apenas colocando um nome de módulo em uma lista de módulos marcados para serem carregados,
não haveria nenhuma penalidade real de desempenho mesmo se cada módulo fosse marcado para ser carregado/descarregado 10 vezes.

O ponto é que todas as configurações devem ser substituídas de arquivos zsh padrão em locais que devem ser mostrados em README.md e esses locais não devem ser alterados com o tempo. Exemplo de tal localização poderia ser $ZDOTDIR/.zshrc_local

Dessa forma, posso puxar esse repositório em cada confirmação e nunca ter conflitos de mesclagem porque minhas configurações substituem as do prezto sem nenhuma penalidade de desempenho.

Eu pessoalmente concordo com você @marko-avlijas - é por isso que não uso o método padrão de carregamento do prezto.

Há um exemplo aqui: https://github.com/belak/dotfiles/blob/5febcfcdb6364db2216145e06c13184ffacb8894/zshrc

Eu vejo os runcoms fornecidos como um ponto de partida. O método "oficial" de gerenciá-los é simplesmente uma sugestão.

Pode valer a pena olhar para uma maneira oficial de customização simples de runcoms, mas por enquanto eu recomendo gerenciá-los você mesmo fora do repositório prezto - eles não são muito complicados.

Além disso, a maioria das configurações de prezto pode ser definida em um arquivo .zpreztorc - isso é suficiente para a maioria das pessoas.