Pode ser "arriscado", mas você pode simplesmente ter. no seu PATH.
Como já foi dito em outros, isso pode ser perigoso, então sempre garanta. está no final do PATH e não no começo.
Supondo que eu esteja na mesma pasta que um arquivo executável, precisaria digitar isso para executá-lo:
./file
Eu prefiro não ter que digitar / , porque / é difícil para eu digitar.
Existe uma maneira mais fácil de executar um arquivo? Idealmente, apenas algumas sintaxes simples como:
.file
ou algo mais, mas mais fácil do que ter que inserir o caracter / .
Talvez haja alguma maneira de colocar algo no diretório /bin ou criar um alias para o interpretador, para que eu possa usar:
p file
. será preenchido automaticamente para ./ (digite . e pressione Tab ) pelo menos nas conchas Bash modernas, então você não deve ter para usar uma solução complexa ou insegura (como PATH modificação).
Se não for autocompletar, talvez seja necessário instalar o pacote "bash-completion".
or.. perhaps giving the interpreter an alias in the bashrc file and then simply
p file
É possível escrever uma dessas funções:
p() {
./"$@"
}
no seu ~/.bashrc . Então você poderá executar p app arguments em vez de ./app arguments . Esta solução funciona para executáveis de qualquer tipo, incluindo scripts e binários.
"$@" expande-se para a lista de argumentos adequadamente citada passada para a função (preservando todos os caracteres especiais de glob ou expansão de variável) e, como apontou @Scott, bash é inteligente o suficiente para preceder ./ ao primeiro um deles, preservando o resto.
Você pode colocar . no seu $PATH adicionando, e. PATH=$PATH:. ao seu /etc/profile , assim você pode executar file escrevendo file , a menos que esteja em outra pasta em seu caminho (por exemplo, /usr/bin/ ). Note que isso geralmente não é uma boa ideia.
Por que é ruim: diga que você está em uma situação em que não confia totalmente no conteúdo de um diretório - você fez o download de algum lugar suspeito e quer investigá-lo antes de executá-lo, ou você é um sysadmin ajudando algum usuário procurando em seu diretório home, etc. Você deseja listar o diretório, então você tenta digitar ls, mas oops, você faz um erro de digitação, e acabou digitando sl em vez disso. O autor deste diretório malicioso previu isso e colocou um shell script chamado "sl", que executa "rm -rf --no-preserve-root /" (ou algo mais malicioso, como instalar um rootkit).
(Obrigado @Muzer pela explicação)
Você pode chamar o intérprete, por exemplo
bash test
Nesse caso, o script será executado mesmo que não tenha uma linha shebang (por exemplo, #!/bin/bash ) nem um bit executável. Você terá que conhecer o intérprete correto para executá-lo também. Você pode ler a primeira linha do arquivo primeiro para certificar-se de chamar o intérprete correto, por exemplo, se a linha shebang disser
#!/usr/bin/env python3
você chamaria
python3 test
Até onde eu sei, não há como consegui-lo, a menos que você inclua o arquivo no caminho env, para poder executá-lo apenas digitando: file
.file não funcionará, pois esse é um nome de arquivo diferente. É um arquivo chamado .file e não ./file .
Eu sinto que a barra pode ser difícil de digitar para você, porque o layout não inglês, talvez? Nesse caso, também acontece comigo, então eu freqüentemente troco o layout do meu teclado para o inglês pressionando Alt + Shift no Windows (eu uso o Linux do ssh)
As pessoas sugeriram adicionar . a PATH ,
o que é perigoso porque cria um risco
que você acidentalmente executará um programa mal-intencionado
plantado em um diretório gravável pelo mundo.
Mas, se você tiver programas executáveis em alguns diretórios
que você possui e só pode ser escrito por você
então é seguro (razoavelmente seguro?) colocar esses diretórios em PATH ,
adicionando uma linha como
PATH=$PATH:~/dev/myprog1:~/dev/myprog2
ao seu arquivo ~/.bashrc .
Claro que isso significa que você pode executar um programa de um desses diretórios
de qualquer lugar no sistema de arquivos.
Por exemplo, você pode cd /etc e digitar foo ,
e executaria ~/dev/myprog1/foo .
Isso tem a menor desvantagem
que você não pode ter programas com o mesmo nome
em mais de um dos diretórios.
Especificamente, se você tiver programas chamados foo
em ~/dev/myprog1 e ~/dev/myprog2 ,
você não poderá executar o segundo, exceto especificando um caminho.
Da mesma forma, se você tem um ~/dev/myprog1/cat - mas por que você quer?
Outra abordagem, se você tiver apenas alguns programas com os quais faz isso, é definir aliases para eles:
alias gizmo='./gizmo'
alias gonzo='./gonzo'
Ou você pode chamar os aliases .gizmo e .gonzo
se você achar isso mais intuitivo.
Na verdade, isso tem, até certo ponto,
o mesmo risco de segurança que colocar . no seu PATH .
Se um usuário mal-intencionado puder ler seu .bashrc e ver seus aliases,
então ele pode colocar um malware chamado gizmo e gonzo em diretórios aleatórios
na esperança de que você irá executá-lo.
É melhor fazer isso usando nomes de caminhos absolutos:
alias gizmo='~/dev/myprog1/gizmo'
alias gonzo='~/dev/myprog2/gonzo'
A propósito, você deve evitar nomear um executável test ,
porque esse é um comando interno do shell,
e você pode executar um programa com esse nome
apenas especificando um caminho ou algum outro truque.
Para expandir a resposta de Zanna sobre intérpretes (desculpe, nenhum representante para um comentário): um "intérprete" para executáveis nativos (também conhecido como arquivos ELF binários) é o carregador dinâmico ( ld.so ), mas normalmente não entende o sintaxe que você quer:
$ /usr/lib/ld-linux-x86-64.so.2 program
program: error while loading shared libraries: program: cannot open shared object file
$ /usr/lib/ld-linux-x86-64.so.2 ./program
<program is launched>
(a menos que você faça um link simbólico para o ld.so no seu caminho, você ainda precisará escrever / s)
Se tivermos permissão para começar a configurar as coisas
mkdir -p ~/.local/bin
cat > ~/.local/bin/x << 'EOF'
#!/bin/sh
N="$1"
shift
exec "./$N" "$@"
EOF
chmod a+x ~/.local/bin/x
A maioria das distros modernas já inclui ~ / .local / bin em $ PATH (adicione export PATH="$HOME/.local/bin:$PATH" ao seu ~/.profile se o seu não tiver). Então você pode usar x file para executar ./file .
Não tente definir um comando . . O comando . script já executa script no shell atual. Isso permite que script defina variáveis de ambiente para o shell atual.
Se tivermos permissão para criar scripts auxiliares, você poderá criar um auxiliar que adicione o pwd ao PATH e, em seguida, execute
. pathhelper #adds pwd to path
file #now it can be run without ./
Isso evita adicionar "." para o caminho e poluindo seu .profile com todos os caminhos em que você pode, em algum momento, executar alguma coisa.
Podemos levar essa abordagem um passo adiante fazendo um auxiliar que lança um novo shell com um PATH modificado. Se tomar um diretório como um parâmetro (usando o pwd como padrão), ele funcionará como um pushd que edita o caminho. Você pode ter que estar ciente de que quaisquer alterações em outras variáveis de ambiente serão perdidas ao sair do subshell, mas em um shell de longa execução, sua variável PATH não ficará toda confusa. Dependendo de seus fluxos de trabalho, isso pode ser vantajoso.
:outer shell prompt$; subshellpathhelper # launches a subshell with modified PATH
: subshell prompt $ ; file # in the subshell it can be run without ./
Mas eu acho que se você quisesse usar isso, poderia hackar pushd e popd para que eles pudessem fazer as mesmas modificações no caminho sem fazer uma subshell que perderia outras alterações.
pushd --path ~/some/path/ # normal pushd plus adds target to path
file # it can be run without ./ until you popd
(Você não pode fazer o mesmo com cd porque não tem um análogo para popd .)
Você também pode criar um par de ajudantes dedicados para apenas enviar e exibir entradas PATH. O que funciona melhor depende dos seus padrões de uso.
Você pode usar a sintaxe . script.sh desde que o script que você deseja executar esteja no diretório atual.
Você também pode prefixar com o interpretador, como sh ou bash.
exemplo: bash script.sh
Tags executable filenames