Executar como .test em vez de ./test

Supondo que eu esteja na mesma pasta que um arquivo executável, eu precisaria digitar isto para executá-lo:

./file

Prefiro não precisar digitar /, porque /é difícil para mim digitar.

Existe uma maneira mais fácil de executar um arquivo? Idealmente, apenas algumas sintaxes simples, como:

.file

ou qualquer outra coisa, mas mais fácil do que ter que inserir o /caractere lá.

Talvez haja alguma maneira de colocar algo no /bindiretório ou criar um alias para o intérprete, para que eu possa usar:

p file

Pode ser "arriscado", mas você poderia ter. no seu CAMINHO.

Como já foi dito em outros, isso pode ser perigoso, portanto, sempre garanta. está no final do CAMINHO e não no começo.

.será preenchido automaticamente para./ (digitar .e pressionar Tab) pelo menos nos shells modernos do Bash; portanto, você não precisará usar uma PATHsolução complexa ou insegura (como modificação).

Se não for concluído automaticamente, pode ser necessário instalar o pacote "bash-complete".

ou .. talvez dando ao intérprete um alias no arquivo bashrc e simplesmente

   p  file

É possível escrever essa função:

p() {
 ./"$@"
}

no seu ~/.bashrc. Então você poderá executar em p app argumentsvez de ./app arguments. Esta solução funciona para executáveis ​​de qualquer tipo, incluindo scripts e binários.

"$@"expande para uma lista de argumentos passados ​​adequadamente para a função (preservando todos os caracteres especiais da expansão glob ou variável) e, como apontado pelo @Scott, bashé inteligente o suficiente para acrescentar ./ao primeiro deles, preservando o restante.

Você poderia colocar .a sua $PATHadicionando por exemplo, PATH=$PATH:.para o seu /etc/profile, desta forma você pode executar fileapenas por escrito file, a menos que seja em alguma outra pasta no seu caminho (por exemplo /usr/bin/). Observe 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ê o baixou de algum lugar desonesto e deseja investigá-lo antes de executá-lo, ou é um administrador de sistemas ajudando alguns procurando o diretório inicial, etc. Você deseja listar o diretório e tentar digitar ls, mas, oops, você digitou um erro de digitação e acabou digitando sl. O autor deste diretório malicioso antecipou isso e colocou um script de shell chamado "sl", que executa 'rm -rf --no-preserve-root /' (ou algo mais malicioso como instalar um rootkit).

(Obrigado @Muzer pela explicação)

Você pode ligar para 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ê precisará conhecer o intérprete correto para executá-lo também. Você pode ler a linha shebang do arquivo primeiro para certificar-se de ligar para o intérprete correto, por exemplo, se a linha shebang indicar

#!/usr/bin/env python3

você ligaria

python3 test

Até onde eu sei, não há como alcançá-lo, a menos que você inclua o arquivo no caminho env, portanto, você pode executá-lo apenas digitando: file

.filenão funcionará, pois esse é um nome de arquivo diferente. É um arquivo chamado .filee não ./file.

Sinto que a barra pode ser difícil de digitar para você, porque o layout não está em inglês, talvez? Nesse caso, isso também acontece comigo; portanto, frequentemente troco o layout do meu teclado para o inglês pressionando Alt + Shift no Windows (eu uso o Linux do ssh)

As pessoas sugeriram a adição .de PATH, o que é perigoso porque cria o risco de você acidentalmente executar um programa malicioso plantado em um diretório gravável em todo o mundo. Mas, se você tem programas executáveis em alguns diretórios que você possui e são gravável apenas por você, então é seguro (bastante seguro?) Para colocar aqueles diretor (es) em PATH, adicionando uma linha como

PATH=$PATH:~/dev/myprog1:~/dev/myprog2

para o seu ~/.bashrcarquivo. Claro que isso significa que você pode executar um programa em um desses diretórios de qualquer lugar do sistema de arquivos. Por exemplo, você poderia cd /etcdigitar fooe ele seria executado ~/dev/myprog1/foo. Isso tem a pequena desvantagem de 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 ambos ~/dev/myprog1e ~/dev/myprog2, não poderá executar o segundo, exceto especificando um caminho. Da mesma forma, se você tem um ~/dev/myprog1/cat- mas por que você gostaria?

Outra abordagem, se você tiver apenas alguns programas com isso, é definir aliases para eles:

alias gizmo='./gizmo'
alias gonzo='./gonzo'

Ou você pode chamar os apelidos .gizmoe, .gonzo se achar mais intuitivo.

Na verdade, isso tem, até certo ponto, o mesmo risco de segurança que você coloca .no seu PATH. Se um usuário mal-intencionado puder ler seu .bashrce ver seus aliases, ele poderá colocar o malware chamado gizmoe gonzoem diretórios aleatórios na esperança de que você o execute. É melhor usar esses nomes de caminho 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, sem repetições para comentar): um "intérprete" para executáveis ​​nativos (também conhecidos como arquivos binários ELF) é o loader dinâmico ( ld.so), mas normalmente não entende a sintaxe que você deseja:

$ /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>

(também, a menos que você faça um link simbólico ld.sopara o caminho, você ainda precisará escrever /s)

Se pudermos 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

As distribuições mais modernas incluem ~ / .local / bin no $ PATH (adicione export PATH="$HOME/.local/bin:$PATH"ao seu ~/.profilese o seu não for o caso). Então você pode usar x filepara executar ./file.

Não tente definir um .comando. O comando . scriptjá é executado scriptno shell atual. Isso permite scriptdefinir variáveis ​​de ambiente para o shell atual.

Se pudermos criar scripts auxiliares, você poderá criar um auxiliar que adicione o pwd ao PATH e execute

. pathhelper    #adds pwd to path
file            #now it can be run without ./

Isso evita adicionar "." ao caminho e poluindo seu .profile com todos os caminhos em que você possa, em algum momento, querer executar algo.

Podemos levar essa abordagem um passo adiante, criando um auxiliar que lança um novo shell com um PATH modificado. Se usar um diretório como parâmetro (usando o pwd como padrão), ele funcionará como um pushdque edita o caminho. Você pode estar ciente de que quaisquer alterações em outras variáveis ​​de ambiente seriam perdidas ao sair do subshell, mas em um shell de longa execução, sua variável PATH não ficará confusa. Dependendo dos 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 acho que se você quisesse rodar com ele, poderia hackear pushde popdassim eles podem fazer as mesmas modificações no caminho sem fazer um subshell que perderá 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 cdporque não possui um análogo popd.)

Você também pode criar um par de ajudantes dedicados para pressionar e abrir as entradas PATH. O que funciona melhor realmente depende dos seus padrões de uso.

Você pode usar a . script.shsintaxe enquanto o script que você deseja executar estiver no diretório atual.

Você também pode prefixar o intérprete, como sh ou bash. exemplo:bash script.sh