6

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...
works
[root@localhost ~] # ...|cat && echo works
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>

EDIT2:

[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' "$@";
    retval=$?;
else
    if [[ -n "${BASH_VERSION-}" ]]; then
        printf 'bash: %scommand not found\n' "${1:+$1: }" 1>&2;
    fi;
fi;
return $retval
}
loa_in_
  • 388
  • 1
  • 9
  • This behaviour doesn't happen on my 4.3.30(1)-release. –  Nov 09 '16 at 01:36
  • My version isn't even on [official ftp](ftp://ftp.gnu.org/pub/gnu/bash/). It's latest from Fedora 24 repository at the time of writing. Might be Fedora specific then. – loa_in_ Nov 09 '16 at 01:42
  • 1
    What's the output of `declare -f command_not_found_handle` for you? – TNW Nov 09 '16 at 01:47
  • Apparently https://rpmfind.net/linux/rpm2html/search.php?query=bash –  Nov 09 '16 at 01:49
  • @TNW I added output. It's Fedora's default one. This might be it... – loa_in_ Nov 09 '16 at 01:51
  • 1
    Confirmed, without `command_not_found_handle` works as expected. – loa_in_ Nov 09 '16 at 01:53
  • How do you know `cat` is never executed? Perhaps its stdin is simply empty. Try substituting `wc` for `cat`, that should show `0 0 0` if it's run with empty input. – wurtel Nov 09 '16 at 09:24
  • Oh, damn, @wurtel , you're right. It was late night yesterday - wc shows `0 0 0`. I'll edit out my silliness. – loa_in_ Nov 09 '16 at 17:58
  • Oh, there's a duplicate even. Then I'll just leave this as a feed for google engine, given I got was excited and verbose yesterday. – loa_in_ Nov 09 '16 at 18:01

1 Answers1

3

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.

loa_in_
  • 388
  • 1
  • 9
  • 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 09 '16 at 02:08
  • I just did. *Severity: Low* seems still way too high for this... – loa_in_ Nov 09 '16 at 02:37