Eseguire come .test anziché ./test

Supponendo che io sia nella stessa cartella di un file eseguibile, dovrei digitare questo per eseguirlo:

./file

Preferirei non dover scrivere /, perché /è difficile per me scrivere.

C'è un modo più semplice per eseguire un file? Idealmente solo una semplice sintassi come:

.file

o qualcos'altro ma più facile che dover inserire il /personaggio lì.

Forse c'è un modo per mettere qualcosa nella /bindirectory o creare un alias per l'interprete, in modo che io possa usare:

p file

Può essere "rischioso" ma potresti semplicemente averlo. nel tuo PERCORSO.

Come è stato detto in altri, questo può essere pericoloso, quindi assicurati sempre. è alla fine del PERCORSO piuttosto che all'inizio.

.si completerà automaticamente per./ (digitare .e premere Tab) almeno nelle moderne shell Bash, quindi non dovresti usare una soluzione complessa o insicura (come la PATHmodifica).

Se non si completa automaticamente, potrebbe essere necessario installare il pacchetto "bash-completamento".

o .. forse dare all'interprete un alias nel file bashrc e poi semplicemente

   p  file

È possibile scrivere una tale funzione:

p() {
 ./"$@"
}

nel tuo ~/.bashrc. Quindi sarai in grado di eseguire p app argumentsinvece di ./app arguments. Questa soluzione funziona per eseguibili di qualsiasi tipo, inclusi script e binari.

"$@"si espande in un elenco di argomenti opportunamente citato passato alla funzione (preservando tutti i caratteri speciali dall'espansione globale o variabile) e, come sottolineato da @Scott, bashè abbastanza intelligente da anteporre ./al primo di essi, preservando il resto.

Potresti metterti .al tuo $PATHaggiungendo ad esempio PATH=$PATH:.al tuo /etc/profile, in questo modo puoi eseguire filesemplicemente scrivendo file, a meno che non sia in qualche altra cartella nel tuo percorso (ad esempio /usr/bin/). Si noti che questa non è generalmente una buona idea.

Perché è brutto: supponi di trovarti in una situazione in cui non ti fidi completamente del contenuto di una directory: l'hai scaricato da qualche parte malvagio e vuoi investigarlo prima di eseguirlo, oppure sei un amministratore di sistema che aiuta alcuni guardando la loro home directory, ecc. Si desidera elencare la directory, quindi si tenta di digitare ls, ma oops, si fa un errore di battitura e si è finito invece a digitare sl. L'autore di questa directory dannosa lo ha anticipato e ha inserito uno script shell chiamato "sl" che esegue 'rm -rf --no-preserv-root /' (o qualcosa di più dannoso come l'installazione di un rootkit).

(Grazie @Muzer per la spiegazione)

Puoi chiamare l'interprete, per esempio

bash test

In questo caso, lo script verrà eseguito anche se non ha né una riga shebang (ad esempio #!/bin/bash) né un bit eseguibile. Dovrai conoscere anche l'interprete corretto per eseguirlo. Puoi leggere prima la riga shebang del file per assicurarti di chiamare l'interprete corretto, ad esempio se la riga shebang dice

#!/usr/bin/env python3

tu chiameresti

python3 test

Per quanto ne so, non c'è modo di ottenerlo se non si include il file nel percorso env, quindi è possibile eseguirlo semplicemente digitando: file

.filenon funzionerà poiché si tratta di un nome file diverso. È un file chiamato .filee non ./file.

Sento che la barra potrebbe essere difficile da digitare per te a causa del layout non inglese, forse? In quel caso, succede anche a me, quindi cambio frequentemente il layout della tastiera in inglese premendo Alt + Maiusc in Windows (utilizzo Linux da ssh)

La gente ha suggerito di aggiungere .a PATH, che è pericoloso perché crea un rischio che verrà eseguito accidentalmente un programma dannoso piantato in una directory scrivibile-mondo. Ma, se si dispone di programmi eseguibili in alcune directory che si possiedono e sono scrivibili solo da voi, allora è sicuro (abbastanza sicuro?) Per mettere quelli direttore (i) in PATH, con l'aggiunta di una linea come

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

al tuo ~/.bashrcfile. Ovviamente questo significa che puoi eseguire un programma da una di quelle directory da qualsiasi parte del filesystem. Ad esempio, è possibile cd /etce digitare fooe verrebbe eseguito ~/dev/myprog1/foo. Ciò ha il piccolo inconveniente di non poter avere programmi con lo stesso nome in più di una directory. In particolare, se hai programmi chiamati foo in entrambi ~/dev/myprog1e ~/dev/myprog2, non sarai in grado di eseguire il secondo se non specificando un percorso. Allo stesso modo se hai un ~/dev/myprog1/cat- ma perché dovresti farlo?

Un altro approccio, se hai solo alcuni programmi con cui lo fai, è definire alias per loro:

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

Oppure puoi chiamare gli alias .gizmoe .gonzo se lo ritieni più intuitivo.

In realtà, questo ha, in una certa misura, lo stesso rischio per la sicurezza che si presenta .al tuo PATH. Se un utente malintenzionato può leggere il tuo .bashrce vedere i tuoi alias, allora potrebbe mettere malware chiamato gizmoe gonzoin directory casuali nella speranza che tu lo esegua. È meglio fare in modo che questi utilizzino nomi di percorso assoluti:

alias gizmo='~/dev/myprog1/gizmo'
alias gonzo='~/dev/myprog2/gonzo'

A proposito, dovresti evitare di nominare un eseguibile test, perché si tratta di un comando incorporato nella shell, e puoi eseguire un programma con quel nome solo specificando un percorso o qualche altro trucco.

Per espandere la risposta di Zanna sugli interpreti (scusate, nessun rappresentante per un commento): un "interprete" per eseguibili nativi (ovvero file binari ELF) è il caricatore dinamico ( ld.so), ma in genere non comprende la sintassi desiderata:

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

(inoltre, a meno che non ti colleghi simbolicamente ld.soal tuo percorso, dovrai comunque scrivere /s)

Se ci è permesso iniziare a configurare le cose

mkdir -p ~/.local/bin
cat > ~/.local/bin/x << 'EOF'
#!/bin/sh
N="$1"
shift
exec "./$N" "$@"
EOF
chmod a+x ~/.local/bin/x

Le distribuzioni più moderne includono ~ / .local / bin in $ PATH (aggiungi export PATH="$HOME/.local/bin:$PATH"al tuo ~/.profilese il tuo non lo fa). Quindi è possibile utilizzare x fileper eseguire ./file.

Non provare a definire un .comando. Il comando è . scriptgià in esecuzione scriptnella shell corrente. Ciò consente scriptdi definire le variabili di ambiente per la shell corrente.

Se ci è permesso creare script di supporto, potresti creare un supporto che aggiunge il pwd al PERCORSO, quindi esegui

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

Questo evita di aggiungere "." al percorso e inquinando il tuo .profile con ogni percorso in cui potresti voler eseguire qualcosa.

Possiamo fare un ulteriore passo avanti con questo approccio creando un helper che lancia una nuova shell con un PATH modificato. Se accetta una directory come parametro (usando pwd come predefinito), funzionerebbe come una pushdmodifica del percorso. Potrebbe essere necessario tenere presente che eventuali modifiche ad altre variabili di ambiente andrebbero perse quando si esce dalla subshell, ma in una shell di lunga durata la variabile PATH non sarà ingombra. A seconda dei flussi di lavoro, questo potrebbe essere vantaggioso.

:outer shell prompt$; subshellpathhelper    # launches a subshell with modified PATH
: subshell prompt $ ; file                  # in the subshell it can be run without ./

Ma immagino che se volessi correre con esso, potresti hackerare pushde popdquindi possono apportare le stesse modifiche al percorso senza fare una subshell che perderà altre modifiche.

pushd --path ~/some/path/    # normal pushd plus adds target to path
file                         # it can be run without ./ until you popd

(Non puoi fare lo stesso con cdperché non ha un analogo popd.)

Puoi anche creare una coppia dedicata di helper per fare semplicemente push e pop delle voci PATH. Ciò che funziona meglio dipende davvero dai modelli di utilizzo.

È possibile utilizzare la . script.shsintassi fintanto che lo script che si desidera eseguire si trova nella directory corrente.

Puoi anche aggiungere un prefisso all'interprete, come sh o bash. esempio:bash script.sh