Estou usando o macOS e meu shell é zsh. Por padrão, o diretório inicial do meu sistema é /Users/njohn
. Eu criei um link simbólico para este caminho, /usr/local/home
. coloquei HOME="/usr/local/home"
no meu .zshrc
. Eu fiz isso para que primeiro eu possa cd ..
acessar rapidamente meu diretório inicial e estar /usr/local
onde todos os meus pacotes homebrew e arquivos de configuração estão. É um atalho muito simples. Também gosto de poder usar cd
e chegar ao meu caminho com link simbólico em vez do caminho normal, que fica longe no sistema de arquivos de coisas das quais gostaria de me sentir mais próximo.
Isso poderia quebrar alguma coisa? Existe uma maneira mais segura ou melhor de realizar a mesma coisa?
Responder1
Isenção de responsabilidade: Eu não uso e não usei MacOS, então não tenho certeza de quais irregularidades ou diferenças sutis podem existir - se houver - entre Mac e *nix.
Para responder à sua pergunta, o único cenário que eu poderia imaginar "quebra" com esta configuração é quando um determinado programa tenta fazer algo com seu diretório inicial e não segue links simbólicos por padrão (ou não segue, por algum motivo) . Se qualquer programa hipotético tentar ler/gravar algum arquivo em seu diretório inicial e não resolver seu /usr/local/home
link simbólico, as coisas provavelmente irão quebrar. Embora a probabilidade de tal cenário esteja além de mim.
Dito isto, acho que seria melhor usar uma abordagem que não modificasse sua $HOME
variável. Alterar sua $HOME
variável para algo diferente do que o sistema entende ser seu diretório inicial durante a vida útil de cada shell interativo que você inicia é feio, hackeado e pode causar problemas sutis. Vou lhe fornecer três alternativas melhores.
Opção 1: um link simbólico colocado de forma mais apropriada
Se você quiser manter um link simbólico, simplesmente crie um link simbólico para /usr/local
o seu diretório inicial, livre-se do /usr/local/home
link que você tem agora e remova a linha que altera sua $HOME
variável do seu arquivo .zshrc
. Por exemplo:
% [~] ln -s /usr/local uloc
% [~] cd uloc
% [~/uloc] realpath .
/usr/local
Semelhante ao que você tem atualmente, você pode acessar rapidamente /usr/local do seu diretório inicial, exceto que desta forma você não precisa alterar o $HOME
.
Opção 2: diretórios nomeados
Como você está usando Zsh, eu recomendaria usar umdiretório nomeado. Em vez de HOME=/usr/local/home
, faça algo como o seguinte, substituindo uloc
por um nome abreviado de sua escolha:
uloc=/usr/local
Então, você pode mudar rapidamente para este diretóriode qualquer lugardas seguintes maneiras:
# With no special options set
% cd ~uloc
# Slightly shorter
% setopt cdable_vars
% cd uloc
# Even shorter
% setopt cdable_vars auto_cd
% uloc
Como você pode ver, se você tiver uma variável que se expande para um caminho, você poderá cd
acessá-la no Zsh se prefixá-la com um ~
caractere, semelhante a como você pode usá-la ~user
como um atalho para /home/user
. Você pode ter quantos diretórios nomeados desejar, para ter acesso rápido aqualquerdiretório que você usa com frequência, não apenas /usr/local
como no seu caso.
A cdable_vars
opção permite que você omita ~
diretórios nomeados ao usar cd
e auto_cd
significa que se você inserir um "comando" que é na verdade um diretório - nomeado ou literal - o Zsh irá automaticamente cd
para esse diretório. A combinação desses dois permite acesso rápido a um diretório desejadoNão importa onde você está. Contrário aOpção 1, já que você não está contando com um link simbólico, cd
vá para este diretório nomeadoirá realmente colocá-lo nesse diretório, tal que pwd
retornaria /usr/local
e não /Users/njohn/uloc
.
Opção 3: usando CDPATH
Esta abordagem pode ser usada isoladamente ou em conjunto comopção 2.
Você também pode usar $CDPATH
, que é uma variável especial $PATH
que contém uma lista de diretórios. Ao contrário $PATH
, porém, os diretórios $CDPATH
serão usados como "raiz" para caminhos relativos fornecidos cd
se o caminho fornecido não for encontrado no diretório atual. Para demonstrar, considere o seguinte:
# Zsh ties lowercase variants of the *PATH variables together as arrays. See zshparam(1) for details
% [~/foo] cdpath=(/usr/local)
% [~/foo] ls
bar/ baz/
% [~/foo] cd share
% [/usr/local/share]
Como não havia nenhum diretório nomeado share
em ~/foo
, Zsh consultou $CDPATH
locais onde share
poderia haver um diretório filho. Como /usr/local
estava em $CDPATH
e share
é um diretório filho de /usr/local
, você pode fazer isso cd share
de dentro de ~/foo
. Você também pode ir mais fundo; por exemplo, se stuff
fosse um subdiretório de /usr/local/share
, você poderia chegar lá executando cd share/stuff
.
Observação:ao contrário do Bash, o Zsh sempre procurará no diretório atualantestentando diretórios em $CDPATH
,a menos quea .
está incluído em $CDPATH
. Nesse caso, o Zsh segue estritamente a ordem dos diretórios em $CDPATH
.
Isso permite ainda mais comodidade, já que como você disse, muitas vezes você precisa acessar seus pacotes e configurações de homebrew, você pode cd
entrar em um desses subdiretórios de qualquer lugar, sem precisar de qualquer tipo de prefixo!
Como já mencionado, você pode combinar isso com diretórios nomeados. Para extrair um exemplo dos meus próprios dotfiles:
ZSH=~/.zsh
cdpath=(~/.zsh)
# I split my configuration up into separate files that live in separate
# directories, which all live under a 'modules' directory inside ~/.zsh
% [~] cd modules/directory
% [~ZSH/modules/directory] cd modules/git
% [~ZSH/modules/git]
Leitura adicional
Eu recomendo se familiarizar mais com o Zsh e seus diversos recursos*. Aqui estão algumas páginas de manual e outros tópicos que você pode examinar:
symlink(7)
— Descreve os links simbólicos em detalhes e como eles interagem.zshexpn(1)
, "Diretórios nomeados estáticos" - explica os diretórios nomeados e o restante da página de manual descreve todas as formas de expansão no Zsh.zshparam(1)
, "PARÂMETROS USADOS PELO SHELL" — Inclui descrições para variáveis especiais comocdpath
e similareszshoptions(1)
— Detalha todas as opções que controlam o comportamento do Zsh por meio dosetopt
arquivo interno. Inclui explicações mais detalhadas sobrecdable_vars
eauto_cd
do que esta resposta fornece.