Pourquoi dois-je toujours taper «./» devant un exécutable pour l'exécuter sous Linux?

Quand je compile egxc par:

GCC x.c -o x

Pour exécuter le résultat, je dois écrire:

./x

Et juste en tapant:

Échoue avec ce message:

x: commande introuvable

Cela signifie que Linux ne le recherche pas dans le répertoire courant! Existe-t-il (j'en suis sûr) un problème raisonnable derrière ce comportement?

linux shell

— Yasser Zamani
source

Parce que ce sont les règles.

— Daniel R Hicks

@DanH: Alors expliquez "les règles" s'il vous plaît.

— Torben Gundtofte-Bruun

Réponses:

Parce que par défaut, le répertoire de travail actuel n'est pas dans la PATHvariable.

Il s'agit d'une mesure de sécurité / commodité. Si vous avez des binaires / scripts appelés par exemple cd, lsetc. dans votre répertoire de travail actuel, il serait très ennuyeux si elles étaient gérées par défaut.

— Oliver Charlesworth
source

La réponse n'est que partiellement correcte. Le problème pourrait être entouré si le répertoire en cours n'était utilisé que comme dernière option. Ensuite, les outils standard seraient toujours trouvés en premier.

— utilisateur inconnu

En outre, les commandes intégrées shell prennent precendence (lorsque vous tapez cddans bash, il exécute une routine interne à bash et non /bin/cd) à moins que vous avec `préfixer .`

— LawrenceC

L'une des mesures de sécurité d'origine * nix, elle force l'exécution des binaires compilés par le système ou l'administrateur qui se trouvent dans la commande de chemin affecté par le système. Rien de pire qu'une personne pour se connecter en tant que root sur une question du service d'assistance, aller dans un répertoire utilisateur, taper ls et trouver qu'ils ont chargé une bombe laissée par un utilisateur.

— Fiasco Labs

@userunknown: Et la première fois que slvous avez fait une faute de frappe , vous avez le même problème. Seuls les répertoires approuvés doivent être dans $PATHet les chemins d'accès relatifs comme ne. sont jamais un répertoire approuvé pour un shell interactif.

@Basic: Si je tape rm -r targetquand je voulais dire, rm -f targetil n'y a généralement aucune différence. Si je tape rm -f targetquand je voulais dire rm -r target, soit il n'y a pas de différence, soit la suppression échoue. De plus, je pense que chaque fois avant de taper rm, surtout si j'ajoute -fou -rou un glob - c'est une commande dangereuse par sa nature. Personne ne pense avant lsing.

Cela signifie que le répertoire courant n'est pas dans la variable $ PATH.

— James
source

Vous pouvez résoudre ce problème en ajoutant le répertoire actuel (représenté par un seul point) à la PATHvariable d'environnement.
La façon de le faire dépend du shell que vous utilisez.
si vous utilisez bash, vous pouvez ajouter la ligne export PATH=$PATH:.au .bashrcfichier dans votre répertoire personnel.
si vous utilisez csh ou tcsh, ajoutez la ligne set PATH = ($PATH .)au fichier .cshrc dans votre répertoire personnel.
À mon humble avis, pour un ordinateur de bureau à domicile, c'est une chose acceptable à faire - en termes de sécurité.

— kroiz
source

Je ne savais pas qu'on pouvait ajouter. à PATH, cependant, cela réduira la sécurité, non?

— Yasser Zamani