2

This evening, I accidentally typed in

.. blah

at the bash command line (Fedora 27, bash 4.4.12). To my surprise, it did (apparently) nothing, but gave no error. How come?

I get the same effect with .. on its own, with no argument.

I wondered whether it could have been treated as . ., i.e. source the current directory, but when I try that, it gives an error to say that . is a directory.

If I try three dots, it suggests trying two:

[james@melissa ~] $ ... bash: ...: command not found... Similar command is: '..' [james@melissa ~] $

so it certainly on some level thinks that the command exists. There's no man page for it, though, and .. --help doesn't give any output.

But perhaps most weirdly of all, it seems that if I execute .., with or without an argument, then I get an exit code of 127, which is the exit code for trying to run a non-existent command. So on some level it also thinks the command doesn't exist.

It doesn't appear to be related to the existence of a directory called ..; or, at least, I do get an error if I type the name of any other directory on its own, and .. doesn't throw an error even if I'm in the root directory, where there's no such directory as ..

All I can guess is that it's not really a command, but that the error message is being suppressed for some reason.

Any other ideas?

EDIT: this turns out to be the same underlying problem as in linked post, although with different symptoms: there, any command starting with a . silently fails. That is not the case here, where only .. has this effect. It seems that the bug has been partly fixed, but not completely.

Improve this question
7
  • What does type .. show? Commented Jan 24, 2018 at 22:19
  • bash: type: ..: not found Commented Jan 24, 2018 at 22:20
  • @StephenKitt I've edited the post to demonstrate that this is not a duplicate. Commented Jan 25, 2018 at 10:27
  • Note that with shopt -s autocd, .. would be valid. Commented Jan 25, 2018 at 10:44
  • 1
    @chiastic-security thanks. Note that the link at the top of this question is introduced by “This question already has an answer here”, which is correct (with the updated information in the answer to the linked question). So I think the duplicate link is still appropriate (even though the questions aren’t strictly identical). Commented Jan 25, 2018 at 11:03

1 Answer 1

Reset to default
-1

I tried this on my system (also using bash-4.4.12) and got -bash: ..: command not found, so it's not an intrinsic. My guess is that you have an alias set somewhere.

To verify whether this could be the case, I tried the following:

# alias ..='echo Hello' # .. Hello #
Improve this answer
4
  • 2
    No, it’s the command_not_found handling, see the suggested duplicate. Commented Jan 24, 2018 at 22:30
  • @StephenKitt I'm not convinced this is a duplicate. In the linked question, anything starting with a . fails silently, but on mine, that's not true. It's only exactly two dots that has that effect for me. That makes it different. Commented Jan 25, 2018 at 7:48
  • @chiastic-security there’s an easy way to find out: run unset -f command_not_found_handle, then try .. again — if it fails with bash: ..: command not found, the command_not_found handling is at fault, otherwise it’s not. The different behaviour you’re getting does suggests a difference though — bash on my Fedora 27 behaves as in the linked question, not just with ... I recommend commenting on your question instead of this answer, or better yet, editing your question: that will be more visible for a re-open review. Commented Jan 25, 2018 at 8:11
  • 1
    @chiastic-security it turns out this is the remnants of the command_not_found handling, as recently updated in FC27 (see my updated answer on the linked question). Commented Jan 25, 2018 at 9:41

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.