. é o diretório atual. Então o comando está dizendo ao shell para procurar o executável no diretório atual.
Não confunda com . foo , que é um comando completamente diferente.
Eu vi muitas vezes comandos do console como
./redis-server
ou
./mongo
o que exatamente ./ significa?
Quando você executar um comando sem nenhum prefixo, os sistemas Unix procurarão o comando em PATH . Por exemplo, se você digitar ls , o Unix percorrerá todos os caminhos listados em PATH para localizar o binário ls .
Por exemplo, vamos supor que seu PATH esteja definido como /bin:/usr/bin:/usr/local/bin , então digitar ls fará com que seu shell encontre o comando em /bin/ls e o execute.
Os sistemas Unix devem avaliar os caminhos na ordem em que estão listados em PATH . Portanto, se você tiver vários ls instalado, ele executará o primeiro encontrado, ignorando os outros. Portanto, no exemplo acima, você pode ter outro ls instalado em /usr/local/bin/ls , que nunca é usado se você digitar apenas ls . Se você quiser executar /usr/local/bin/ls , então você pode modificar PATH ou usar o caminho absoluto digitando /usr/local/bin/ls .
Agora chega ao seu prefixo ./ . O . está simplesmente referindo a pasta atual. Portanto, se você prefixar um comando com ./ , seu shell procurará o comando na pasta atual.
Na verdade
./command
é idêntico a
'pwd'/command
ou (na BASH)
${PWD}/command
Como já foi mencionado na linha de comando do Windows, você pode usar apenas command se quiser executar command.exe da pasta atual. Isso ocorre porque o Windows primeiro procura implicitamente na pasta de trabalho atual para o binário antes de pesquisar o caminho.
Infelizmente isso é bastante inseguro. Vamos imaginar que gostaria de roubar informações do usuário às quais não tenho acesso como usuário normal. Vou apenas colocar um script muito simples em meu diretório pessoal chamado 'ls' com o seguinte conteúdo:
#!/bin/bash
cp /etc/shadow /home/my-user > /dev/null 2>&1
chown my-user /home/my-user/shadow > /dev/null 2>&1
/bin/ls $*
Em seguida, torne-o executável.
Depois, ligo para o administrador do sistema e conto-lhe uma história sobre alguns nomes de arquivos bastante estranhos no meu diretório pessoal. É muito provável que o administrador faça o login no shell (espero que seja como root) no meu diretório e execute ls . O que aconteceria é que, em vez de /bin/ls , o administrador do sistema executaria meu script ls , que apenas coloca uma cópia de /etc/shadow em minha pasta pessoal. Bem, o administrador provavelmente se perguntaria por que esse ls não listará os nomes dos arquivos. Assim, o script apenas executa o comando "real" /bin/ls na última linha.
Assim, para evitar tais problemas, a maioria dos sistemas Unix modernos não inclui o diretório atual ( . ) no caminho de pesquisa. Basicamente, se um comando é executado sem especificar o caminho completo, o shell apenas executará binários dentro do caminho que normalmente inclui apenas caminhos confiáveis (não graváveis pelo usuário). Quando você vê ./mongo em uma documentação, isso significa apenas que você deve certificar-se de que mongo da pasta correta seja executada, e não algum mongo binário em algum lugar no caminho.
Se você costuma executar binários a partir do caminho atual, pode simplesmente adicionar "." para a lista PATH manualmente:
export PATH=".:$PATH"
A partir de agora, o shell sempre procurará binários no diretório atual primeiro. Como escrito acima, isso é altamente perigoso, pois você deve verificar o diretório de trabalho atual para binários toda vez que executar um comando - mesmo antes de executá-lo. Infelizmente, para checar o diretório atual para binários, usaria o 'ls' que já poderia executar um binário que você não esperaria.
Pessoalmente, utilizo frequentemente o seguinte na minha $HOME/.profile :
export PATH="~/bin:$PATH"
Isso me permite colocar alguns scripts na minha pasta $HOME/bin e executá-los sem precisar especificar o caminho completo. Mas lembre-se que $HOME/bin é um caminho confiável para mim também.
Outra pequena nota. Cada diretório (mesmo os vazios) contém dois links físicos. Verifique ls -a output:
.
..
A entrada . refere-se ao diretório atual enquanto a entrada .. é vinculada ao diretório pai. Isso está habilitando caminhos relativos. Claro que também permite definições recursivas como ././././././command executar command como . sempre se refere ao mesmo diretório.
Você também pode executar algo como /bin/../bin/./././../bin/ls , que é totalmente válido.
Espero que isso esclareça um pouco sobre o que são as entradas . e .. .