Exécuter en tant que .test plutôt que ./test

En supposant que je suis dans le même dossier qu'un fichier exécutable, je devrais taper ceci pour l'exécuter:

./file

Je préfère ne pas avoir à taper /, car il /m'est difficile de taper.

Existe-t-il un moyen plus simple d'exécuter un fichier? Idéalement, juste une syntaxe simple comme:

.file

ou autre chose mais plus facile que d'y insérer le /caractère.

Il y a peut-être un moyen de mettre quelque chose dans le /binrépertoire, ou de créer un alias pour l'interpréteur, afin que je puisse utiliser:

p file

Cela peut être "risqué", mais vous pourriez en avoir. dans votre CHEMIN.

Comme cela a été dit dans d'autres, cela peut être dangereux, alors assurez-vous toujours. est à la fin du CHEMIN plutôt qu'au début.

.se complétera automatiquement pour./ (taper .et appuyer Tab) au moins dans les shells Bash modernes, donc vous ne devriez pas avoir à utiliser une PATHsolution complexe ou non sécurisée (comme une modification).

S'il ne se complète pas automatiquement, vous devrez peut-être installer le package "bash-complètement".

ou .. peut-être en donnant à l'interprète un alias dans le fichier bashrc, puis simplement

   p  file

Il est possible d'écrire une telle fonction:

p() {
 ./"$@"
}

dans votre ~/.bashrc. Ensuite, vous pourrez exécuter p app argumentsau lieu de ./app arguments. Cette solution fonctionne pour les exécutables de tout type, y compris les scripts et les binaires.

"$@"se développe en une liste d'arguments correctement citée passée à la fonction (en préservant tous les caractères spéciaux de l'expansion glob ou variable) et, comme l'a souligné @Scott, bashest assez intelligent pour ajouter ./le premier d'entre eux, en préservant le reste.

Vous pouvez mettre .à votre $PATHen ajoutant par exemple PATH=$PATH:.à votre /etc/profile, de cette façon, vous pouvez exécuter filesimplement en écrivant file, sauf s'il se trouve dans un autre dossier de votre chemin (par exemple /usr/bin/). Notez que ce n'est généralement pas une bonne idée.

Pourquoi c'est mauvais: disons que vous êtes dans une situation où vous ne faites pas entièrement confiance au contenu d'un répertoire - vous l'avez téléchargé depuis un endroit louche et vous voulez l'examiner avant de l'exécuter, ou vous êtes un administrateur système aidant certains l'utilisateur en regardant dans son répertoire personnel, etc. Vous voulez lister le répertoire, donc vous essayez de taper ls, mais oups, vous faites une faute de frappe, et vous avez fini par taper sl à la place. L'auteur de ce répertoire malveillant a anticipé cela et y a mis un script shell appelé "sl" qui exécute 'rm -rf --no-preserve-root /' (ou quelque chose de plus malveillant comme l'installation d'un rootkit).

(Merci @Muzer pour l'explication)

Vous pouvez appeler l'interprète, par exemple

bash test

Dans ce cas, le script s'exécutera même s'il n'a ni ligne de shebang (par exemple #!/bin/bash) ni bit exécutable. Vous devrez également connaître l'interprète approprié pour l'exécuter également. Vous pouvez d'abord lire la ligne shebang du fichier pour vous assurer d'appeler l'interprète correct, par exemple si la ligne shebang indique

#!/usr/bin/env python3

tu appellerais

python3 test

Pour autant que je sache, il n'y a aucun moyen d'y parvenir à moins d'inclure le fichier dans le chemin env, vous pouvez donc l'exécuter en tapant simplement: file

.filene fonctionnera pas car il s'agit d'un nom de fichier différent. C'est un fichier appelé.file et non ./file.

J'ai l'impression que la barre oblique peut être difficile à taper pour vous car la mise en page n'est pas en anglais, peut-être? Dans ce cas, cela m'arrive aussi, donc j'échange fréquemment ma disposition de clavier en anglais en appuyant sur Alt + Maj dans Windows (j'utilise Linux de ssh)

Les gens ont suggéré d'ajouter .à PATH, ce qui est dangereux car cela crée un risque que vous exécutiez accidentellement un programme malveillant planté dans un répertoire accessible en écriture. Mais, si vous avez des programmes exécutables dans quelques répertoires que vous possédez et qui sont inscriptibles que par vous, alors il est sûr (assez sûr?) Pour mettre les directeur (s) dans PATH, en ajoutant une ligne comme

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

à votre ~/.bashrcdossier. Bien sûr, cela signifie que vous pouvez exécuter un programme à partir de l'un de ces répertoires depuis n'importe où dans le système de fichiers. Par exemple, vous pourriez cd /etcet tapez foo, et il s'exécuterait ~/dev/myprog1/foo. Cela présente l'inconvénient mineur que vous ne pouvez pas avoir de programmes du même nom dans plus d'un des répertoires. Plus précisément, si vous avez des programmes appelés foo dans les deux ~/dev/myprog1et ~/dev/myprog2, vous ne pourrez pas exécuter le second sauf en spécifiant un chemin. De même, si vous avez un ~/dev/myprog1/cat- mais pourquoi voudriez-vous?

Une autre approche, si vous n'avez que quelques programmes avec lesquels vous le faites, consiste à leur définir des alias:

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

Ou vous pouvez appeler les alias .gizmoet .gonzo si vous trouvez cela plus intuitif.

En fait, cela a, dans une certaine mesure, le même risque de sécurité que de mettre .dans votre PATH. Si un utilisateur malveillant peut lire votre .bashrcfichier et voir vos alias, il peut placer des logiciels malveillants appelés gizmoet gonzodans des répertoires aléatoires dans l'espoir que vous les exécuterez. Il vaut mieux utiliser ces noms de chemin absolus:

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

Soit dit en passant, vous devez éviter de nommer un exécutable test, car il s'agit d'une commande intégrée au shell, et vous ne pouvez exécuter un programme avec ce nom qu'en spécifiant un chemin ou une autre astuce.

Pour développer la réponse de Zanna à propos des interprètes (désolé, pas de représentant pour un commentaire): un "interprète" pour les exécutables natifs (alias fichiers ELF binaires) est le chargeur dynamique ( ld.so), mais il ne comprend généralement pas la syntaxe que vous souhaitez:

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

(également, sauf si vous créez un lien symbolique ld.sovers votre chemin, vous devez toujours écrire /s)

Si nous sommes autorisés à commencer à configurer les choses

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

La plupart des distributions modernes incluent déjà ~ / .local / bin dans $ PATH (ajoutez- export PATH="$HOME/.local/bin:$PATH"les ~/.profilesi les vôtres ne le font pas). Ensuite, vous pouvez utiliser x filepour exécuter ./file.

N'essayez pas de définir une .commande. La commande . scripts'exécute déjà scriptdans le shell actuel. Cela permet scriptde définir des variables d'environnement pour le shell courant.

Si nous sommes autorisés à créer des scripts d'aide, vous pouvez créer un assistant qui ajoute le pwd au PATH, puis exécuter

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

Cela évite d'ajouter "." vers le chemin et polluer votre .profile avec chaque chemin dans lequel vous pourriez à un moment donné vouloir exécuter quelque chose.

Nous pouvons pousser cette approche un peu plus loin en créant un assistant qui lance un nouveau shell avec un PATH modifié. S'il prend un répertoire comme paramètre (en utilisant le pwd par défaut), il fonctionnerait comme un pushdqui modifie le chemin. Vous devrez peut-être garder à l'esprit que toute modification des autres variables d'environnement serait perdue lors de la fermeture du sous-shell, mais dans un shell de longue durée, votre variable PATH ne sera pas encombrée. Selon vos workflows, cela peut être avantageux.

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

Mais je suppose que si vous vouliez l'exécuter, vous pourriez pirater pushdet popdainsi ils pourraient apporter les mêmes modifications au chemin sans faire un sous-shell qui perdrait d'autres changements.

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

(Vous ne pouvez pas faire de même avec cdcar il n'a pas d'analoguepopd .)

Vous pouvez également créer une paire dédiée d'aides pour simplement pousser et faire apparaître les entrées PATH. Ce qui fonctionne le mieux dépend vraiment de vos habitudes d'utilisation.

Vous pouvez utiliser . script.sh syntaxe tant que le script que vous souhaitez exécuter se trouve dans le répertoire courant.

Vous pouvez également préfixer l'interpréteur, comme sh ou bash. Exemple:bash script.sh