L'ho appena notato su bash 4.3; il numero di versione esatto è 4.3.42(1)-release (x86-redhat-linux-gnu).
$ ..
$ ...
$ ....
$ .....
Perché il "comando non trovato" non viene richiesto?
$ ...
$ echo $?
$ 127
Ho controllato il $PATH e l'alias niente; Nemmeno l'uomo aiuta.
Il bash viene eseguito su Fedora Linux, ma penso che non sia correlato al sistema operativo.
MODIFICA
Ho appena notato che è lo stesso per qualsiasi comando di avvio del punto
.za
.zaza
..za
..zaza
Risposta accettata:
Ciò è stato causato dalla gestione del comando non trovato in Fedora.
Esecuzione di un comando sconosciuto (incluso ... ecc. se nessun alias corrisponde) provoca command_not_found_handle da eseguire con il comando mancante come parametro (vedi /etc/profile.d/PackageKit.sh per la sua definizione). Nello scenario indicato, il gestore esegue quindi /usr/libexec/pk-command-not-found , sempre con il comando mancante come parametro. In precedenza, pk-command-not-found semplicemente ignorato qualsiasi comando che inizia con . :
if (argv[1][0] == '.')
goto out;
ed è uscito con il codice 127.
Questo comportamento è stato introdotto per correggere Red Hat #1151185, è anche referenziato in Bash non stampa alcun messaggio di errore su comandi non esistenti che iniziano con punto e presenta un bug che richiede una correzione (Red Hat #1292531). È stato in gran parte risolto in FC 27 con aggiornamenti, da PackageKit 1.1.8 (vedi questo commit):ora i comandi con punti iniziali vengono elaborati, solo . e .. vengono ignorati.