3 Maneiras de editar o seu caminho na linha de comando
A variável de ambiente PATH é uma das partes mais importantes da utilização da linha de comando no Linux. Num sistema moderno, é frequentemente uma cadeia muito longa de directórios, todos separados por dois pontos. Se você quiser mudar um item no seu caminho, pode ser irritante ter que digitar e editar um monte de nomes de diretórios diferentes e obter tudo certo. Felizmente, existem algumas maneiras de facilitar. O mesmo se aplica a qualquer variável de ambiente e a maioria das ferramentas que vou mostrar que você vai trabalhar para qualquer uma delas.
Overview
Como a maioria das coisas no Linux, há muitas maneiras de conseguir o seu objetivo. Mesmo que eu tenha dito que havia três maneiras de fazê-lo, provavelmente há um número infinito de maneiras, e aqui está uma que eu não vou contar como parte das três: Use expansion.
No entanto, isto só funciona se quiser adicionar algo ao início ou ao fim de uma variável. Por exemplo, digamos que você queira adicionar ~/foo a PATH:
# add to the end:
PATH="$PATH:~/foo"
# add to the start:
PATH="~/foo:$PATH"
Isso é fácil, mas não ajuda se você quiser apagar ou alterar algo na variável. Também não ajuda se você quiser mudar a ordem de alguns diretórios existentes.
Método 1: O caminho mais difícil
Assumindo que você está dentro de um terminal GUI, você provavelmente tem uma maneira de cortar e colar texto. Assim pode parecer fácil escrever:
echo $PATH
Então pode pegar no texto e, numa nova linha de comando, introduzir PATH=" e colar o resto do texto. Faça as suas alterações, feche a citação, e pressione Enter. Você pode pensar que isso não é muito melhor se você precisar editar o texto existente, mas se você pressionar CONTROL+X, CONTROL+E na bash, você terá uma bela janela de edição onde você pode editar seu comando. Isto funcionará com qualquer comando, e é muito útil quando você está puxando uma longa linha de comando para fora da história que você precisa corrigir.
Como o bash sabe qual editor usar? A variável de ambiente EDITOR. Se você não gosta do editor que ele traz por padrão, altere seu arquivo de inicialização (por exemplo, .bashrc) para definir a variável:
EDITOR=nano
Isso é bom, mas podemos fazer melhor. Afinal, este método requer que você exiba a variável, faça alguma digitação manual, e então faça uma cópia e cola.
Método 2: envedit/pathedit
No GitHub, você encontrará scripts para envedit e pathedit. Estes são scripts simples que você pode colocar em seu sistema em algum lugar que possa ser encontrado (por exemplo, /usr/local/bin). Se você quiser que eles sejam encontrados no caminho, você deve torná-los executáveis (chmod 755).
O problema é que qualquer mudança que um script fizer no ambiente não será mantida após a saída desse script (veja a seção O que é o Ambiente?, abaixo). Como resultado, você tem que fazer o código fonte desses arquivos para que eles funcionem. O script pathedit irá editar o PATH no seu editor favorito enquanto que envedit requer um nome de variável e fará o mesmo trabalho:
# use . or source for these scripts
. pathedit
# or
source pathedit
. envedit PULSE # edit $PULSE
Encómodo ter de se lembrar de os fontes a toda a hora, por isso os scripts têm uma funcionalidade especial. Se você os fontes uma vez no seu .bashrc e passar o argumento alias, os scripts irão configurar um apelido para eles mesmos para que apenas digitando pathedit ou envedit faça o fonte acontecer:
. pathedit alias # now just typing pathedit will work
Como de costume, o script usa $EDITOR para saber qual editor usar. Se você quiser um editor especial somente para este propósito, defina $PATHEDIT_EDITOR ou $ENVEDIT_EDITOR e ele irá sobrepor as configurações usuais. Se isto não estiver definido, o script procura por $EDITOR e $VISUAL antes de definir o padrão para vi.
Método 3: envedit2/pathedit2
O terceiro método também está na mesma página do GitHub. A operação é a mesma que o método 2. Ou seja, você ainda coloca os arquivos em algum lugar e os chama com o argumento alias para configurá-los. No entanto, estes scripts não usam o seu editor de texto. Em vez disso, eles carregam o buffer de linha de comando bash com a string correta para editar. Isto é muito semelhante ao primeiro método, excepto que os passos são automatizados para si.
Note que quando executa qualquer um destes, eles configuram um alias para envedit ou pathedit, para que não utilize os 2 para os utilizar excepto quando os configura. Isso também significa que o último que você configurou “ganha”. Você não pode configurar ambos ao mesmo tempo, a menos que você faça alguma cirurgia de script ou configure seus próprios apelidos.
Quando você executa qualquer um destes scripts, você pode ver um estranho caractere de escape aparecer antes do seu prompt. Esse é o relatório de status que aciona o preenchimento do buffer. É inofensivo e se isso o incomoda, basta pressionar CONTROL+L para redesenhar a tela.
There’s Your Three
If you want to use only these scripts, you are done. Espero que você os ache úteis. Se você não quer saber como e porque tudo isso funciona, você pode parar aqui. Mas se você quiser saber mais sobre o porquê destes scripts serem aliados e como o ambiente funciona, leia em.
O que é o Ambiente?
Você pode pensar no ambiente como uma pequena base de dados que é passada para cada programa. Por exemplo, você provavelmente tem uma variável de ambiente chamada EDITOR que normalmente é definida para algo como vi, emacs, ou nano. Quando um programa precisa chamar um editor de texto, ele vai descobrir qual editor você gosta de usar lendo aquela variável de ambiente.
Quando um programa A inicia outro programa (B), o programa filho recebe uma cópia do ambiente, embora o programa A possa fazer alterações nele antes de lançar B. No entanto, quaisquer alterações que o B fizer só estarão em vigor para B e quaisquer programas que ele iniciar.
Praticamente, isto significa que nada do que você fizer em um programa lançado terá impacto em qualquer outro programa que não tenha iniciado a partir do programa. Este é um problema real nos scripts da shell. Por exemplo, suponha que queria escrever um script que adicionasse ~/foo ao final de PATH. Isto não irá funcionar:
#!/bin/bash
# Bad example
PATH="$PATH:~/foo"
O problema é que o script irá executar na sua própria cópia de bash. Ele alterará apropriadamente a variável PATH e então sairá, fazendo com que a nova cópia de PATH desapareça. É claro, a alteração estaria em vigor para qualquer outra parte do script. Para fazer isso funcionar, você precisaria source o script (e então ele não precisa da linha #!, embora não doa para deixá-lo). Suponha que o nome do script acima era foopath. Você poderia dizer:
source ./foopath
# or the same thing:
. ./foopath
É assim que alguns dos scripts mencionados funcionam, ao fazer sourcing para a shell eles podem alterar o ambiente atual da shell.
É Tudo, Realmente… Exceto
Se você chegou até aqui, parabéns. Espero que você ache estas ferramentas úteis e certifique-se de relatar bugs no GitHub.
Bonus Round
Eu disse anteriormente, que cortar e colar manualmente pode ser a maneira mais difícil. No entanto, há uma outra maneira de fazer isso. Se você tem /etc/inputrc ou ~/.inputrc configurado corretamente você pode digitar (mas não pressione Enter):
PATH=$PATH
Então pressione Alt+Control+E e a shell irá expandir a variável $PATH para você. Entretanto, se você tentar:
PATH="$PATH"
Você verá que expandindo irá perder suas aspas. Você tem que fazer o incômodo:
PATH=\"$PATH\"
Então pressione Alt+Control+E. A saída de bind -P pode dizer-lhe se a função shell-expand-line está ligada a qualquer coisa.