Início / unix / Perguntas / 788467
Accepted
villapx
Asked: 2024-12-21 01:17:10 +0800 CST

Méritos de `cd && pwd` versus `dirname`

  • 772

Alguns dos meus colegas de trabalho preferem escrever o seguinte no topo de seus scripts BASH para determinar o diretório que contém o script:

SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

Enquanto eu prefiro o seguinte:

SCRIPT_DIR="$(dirname "${BASH_SOURCE[0]}")"

(Observe que, na maioria dos casos, não nos importamos em resolver links simbólicos, por isso tendemos a usar estes em vez de eg readlink)

Há algum mérito da cd ... && pwdabordagem em relação à dirnameabordagem -only? Parece que ela está apenas realizando etapas extras para atingir exatamente o mesmo resultado, mas quero ter certeza de que não há nenhuma nuance que eu esteja perdendo.

bash

2 respostas

  1. Best Answer

    O ponto de:

    SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

    O que deveria ser:

    SCRIPT_DIR=$(
  CDPATH= cd -P -- "$(dirname -- "$BASH_SOURCE")" && pwd
)

    É que ele fornece um caminho absoluto (e com -P, o caminho absoluto canônico , o realpath()), enquanto $BASH_SOURCE( $varé a abreviação de ${var[0]}no bash, como no ksh) pode muito bem ser um caminho relativo, como ../file.bash.

    Sem -P, no caso de ../file.bash, cd ..pode muito bem levá-lo a um diretório diferente daquele que o script define como padrão (novamente como no ksh que introduziu o recurso (incorreto) cdfaz uma travessia lógica onde cd ..não, chdir("..")mas sim chdir(dirname($PWD))(e $PWDterá componentes de link simbólico se você tiver cdinserido caminhos com componentes de link simbólico anteriormente).

    Definimos CDPATHpara a string vazia (o que, até onde cdse sabe, é equivalente a desconfigurar), caso esteja definido para outra coisa porque, por exemplo, há uma variável com esse nome no ambiente, pois, do contrário, um cdcom um caminho relativo (como no BASH_SOURCE=dir/file.bashcaso) poderia levá-lo para outro lugar. Pode ser uma boa ideia desconfigurar CDPATHglobalmente, mas se esse script for destinado a ser originado, pode não ser aceitável.

    Observe que isso ainda não funciona corretamente se o nome do diretório BASH_SOURCEou seu caminho real terminarem em caracteres de nova linha (já que a substituição de comando remove todos os caracteres de nova linha finais, não apenas aquele adicionado por dirname/ pwdpara saída) ou se $BASH_SOURCEfor , -/filepor exemplo (como cd -é a abreviação de cd -- "$OLDPWD").

    Abordar o último e, de forma mais geral, ter uma cdabordagem mais próxima do que chdir()é encontrado em linguagens de programação não shell poderia ser feito com uma função auxiliar usando a recomendação POSIX :

    chdir() case $1 in
  (/*) cd -P "$1";;
  ('') echo>&2 'Directory is an empty string'; return 1;;
  ( *) CDPATH= cd -P "./$1";;
esac

    Onde prefixar caminhos relativos com ./evita a necessidade de --e aborda o -problema como ./-contrário a -não é interpretado como o diretório anterior . Veja lá por que a string vazia é tratada especialmente. Esse ./prefixo também desabilita CDPATHo tratamento, então o CDPATH=acima não é necessário, exceto como um lembrete de que esse chdirauxiliar desabilita CDPATHo tratamento.

    No zsh, você faria apenas:

    SCRIPT_DIR=$0:h:P

    Ou:

    SCRIPT_DIR=$0:P:h

    Onde :Pvocê obtém o realpath()e :ho cabeçalho (dirname, como em csh).

    Ambos não necessariamente darão o mesmo resultado se $0forem um link simbólico.

    Eles não apresentam nenhum dos problemas da abordagem bash acima.

    • 15

  2. Francamente, eu diria que ambos são desnecessariamente complicados (e eu estaria errado; veja a resposta de Stéphane que explica que é assim que se faz se você precisa resolver para caminhos absolutos). Mesmo sua versão mais simples ainda está chamando um comando externo onde nenhum é necessário. Por que não fazer apenas:

    script_dir="${BASH_SOURCE%/*}"

    Quanto a esses dois, não vejo nenhum benefício na abordagem ainda mais complicada usando dois comandos externos. Por que executar pwdse você pode usar $PWD, mas por que executar tantos comandos em primeiro lugar? Se você precisasse resolver links simbólicos, então eu poderia entender trazer comandos externos, mas para algo tão simples quanto isso?

    Agora, há casos extremos em que isso falha. Conforme explicado por Stéphane Chazelas em um comentário (agora deletado):

    Isso lhe dá file.bashse $BASH_SOURCEfor apenas file.bash(while dirnamelhe daria .) e a string vazia se $BASH_SOURCEfor /file.bash(where dirnamelhe daria /).

    Se isso é relevante ou não no seu caso é algo que só você pode saber.

    A propósito, você realmente não quer usar CAPS para nomes de variáveis ​​de shell. Como, por convenção , variáveis ​​de ambiente globais são capitalizadas, é uma má prática usar também caps para suas próprias variáveis ​​locais, porque isso pode levar a colisões de nomes e bugs difíceis de encontrar.

    • 11

relate perguntas