I tried searching online for an answer, but the answer (if exists) is overshadowed by other applications of dot in shell scripting. So here goes.

EDIT: Turns out it's related to Fedora's default configuration of command_not_found_handle, so it's not related to bash source code. /EDIT

I found that while bash usually complains about lack of command, or even that whatever I input as command-line is a directory:

[root@localhost tmp] # mkdir test
[root@localhost tmp] # test
[root@localhost tmp] # nonexistent
bash: nonexistent: command not found...
[root@localhost tmp] # test
[root@localhost tmp] # cd test
[root@localhost test] # empty
bash: empty: command not found...
[root@localhost test] # .
bash: .: filename argument required
.: usage: . filename [arguments]
[root@localhost test] # ..

The above are clearly valid and expected. But these:

[root@localhost test] # ....
[root@localhost test] # .........................
[root@localhost test] # .whatever
[root@localhost test] # ..........whatever
[root@localhost test] # ......œę©æąðæćþóœ
[root@localhost test] # .ignored
[root@localhost test] # touch .whatever
[root@localhost test] # .whatever
[root@localhost test] # file .whatever 
.whatever: empty
[root@localhost test] # file .ignored
.ignored: cannot open '.ignored' (No such file or directory)
[root@localhost test] # .ignored
[root@localhost test] # .whatever follows is just discarded
[root@localhost test] # 

are just silently ignoring whatever I happen to type.

And that's not what one would expect. Is there a reason for this behavior?

EDIT: I found a use case!

[root@localhost ~] # ...|cat
[root@localhost ~] # ...|nonexistent
bash: nonexistent: command not found...
[root@localhost ~] # ...|nonexistent && echo works
bash: nonexistent: command not found...
[root@localhost ~] # ...|nonexistent || echo works
bash: nonexistent: command not found...
[root@localhost ~] # ...|cat && echo works
[root@localhost ~] # ...|cat || echo works
[root@localhost ~] # 

It apparently allows one to check whether an executable is on PATH without trying to run it - you can see cat didn't block. It was never executed.

This is kind of ridiculous. Have fun!

[root@localhost ~] # LANG=en bash --version
GNU bash, version 4.3.42(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>


[root@localhost ~] # declare -f command_not_found_handle
command_not_found_handle () 
local runcnf=1;
local retval=127;
[[ $- =~ i ]] || runcnf=0;
[[ ! -S /var/run/dbus/system_bus_socket ]] && runcnf=0;
[[ ! -x '/usr/libexec/packagekitd' ]] && runcnf=0;
[[ -n ${COMP_CWORD-} ]] && runcnf=0;
if [ $runcnf -eq 1 ]; then
    '/usr/libexec/pk-command-not-found' "$@";
    if [[ -n "${BASH_VERSION-}" ]]; then
        printf 'bash: %scommand not found\n' "${1:+$1: }" 1>&2;
return $retval
  • This behaviour doesn't happen on my 4.3.30(1)-release. – user147505 Nov 9 '16 at 1:36
  • My version isn't even on official ftp. It's latest from Fedora 24 repository at the time of writing. Might be Fedora specific then. – loa_in_ Nov 9 '16 at 1:42
  • 1
    What's the output of declare -f command_not_found_handle for you? – TNW Nov 9 '16 at 1:47
  • Apparently rpmfind.net/linux/rpm2html/search.php?query=bash – user147505 Nov 9 '16 at 1:49
  • 1
    Confirmed, without command_not_found_handle works as expected. – loa_in_ Nov 9 '16 at 1:53

Turns out unexpected behavior was because of Fedora's default implementation of command_not_found_handle. Thanks @TNW for reminding me of it's existence.

After unset command_not_found_handle it works as expected.

I don't know if it's a bug or a limitation.

|improve this answer|||||
  • Unexpected behavior, at the very least. Would be very cool if you could file an issue, especially if you feel like investigating it in more detail :) – TNW Nov 9 '16 at 2:08
  • I just did. Severity: Low seems still way too high for this... – loa_in_ Nov 9 '16 at 2:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.