Je viens de le noter sur bash 4.3; le numéro de version exact est 4.3.42(1)-release (x86-redhat-linux-gnu).
$ ..
$ ...
$ ....
$ .....
Pourquoi la "commande introuvable" n'est-elle pas demandée ?
$ ...
$ echo $?
$ 127
J'ai vérifié le $PATH et le alias rien; L'homme n'aide pas non plus.
Le bash fonctionne sur Fedora Linux, mais je pense que ce n'est pas lié au système d'exploitation.
MODIFIER
Je viens de noter que c'est la même chose pour toute commande de démarrage par point
.za
.zaza
..za
..zaza
Réponse acceptée :
Cela a été causé par la gestion de la commande introuvable dans Fedora.
Exécution d'une commande inconnue (y compris ... etc. si aucun alias ne correspond) provoque command_not_found_handle à exécuter avec la commande manquante en paramètre (voir /etc/profile.d/PackageKit.sh pour sa définition). Dans le scénario donné, le gestionnaire exécute ensuite /usr/libexec/pk-command-not-found , encore une fois avec la commande manquante en paramètre. Auparavant, pk-command-not-found simplement ignoré toute commande commençant par . :
if (argv[1][0] == '.')
goto out;
et sorti avec le code 127.
Ce comportement a été introduit pour corriger Red Hat #1151185, est également référencé dans Bash, n'imprime aucun message d'erreur sur des commandes inexistantes commençant par un point et comporte un bogue demandant un correctif (Red Hat #1292531). Cela a été en grande partie corrigé dans FC 27 avec des mises à jour, depuis PackageKit 1.1.8 (voir ce commit) :maintenant les commandes avec des points de tête sont traitées, seulement . et .. sont ignorés.