I just noted this on bash 4.3; exact version number is 4.3.42(1)-release (x86-redhat-linux-gnu).
$ .. $ ... $ .... $ .....
Why do the “command not found” is not prompted ?
$ ... $ echo $? $ 127
I checked the $PATH and the alias nothing; The man is not helping neither.
The bash run on Fedora Linux, but I think it is not related to the OS.
EDIT
I just noted this it the same for any dot starting command
.za .zaza ..za ..zaza
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
This was caused by the command-not-found handling in Fedora.
Running an unknown command (including ... etc. if no alias matches) causes command_not_found_handle to be run with the missing command as parameter (see /etc/profile.d/PackageKit.sh for its definition). In the given scenario, the handler then runs /usr/libexec/pk-command-not-found, again with the missing command as parameter. Previously, pk-command-not-found simply ignored any command starting with .:
if (argv[1][0] == '.')
goto out;
and exited with code 127.
This behaviour was introduced to fix Red Hat #1151185, is also referenced in Bash does not print any error msg upon non-existing commands starting with dot, and has a bug requesting a fix (Red Hat #1292531). It’s largely been fixed in FC 27 with updates, since PackageKit 1.1.8 (see this commit): now commands with leading dots are processed, only . and .. are ignored.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0