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.

  • What does type .. show? – nohillside Jan 24 '18 at 22:19
  • bash: type: ..: not found – chiastic-security Jan 24 '18 at 22:20
  • @StephenKitt I've edited the post to demonstrate that this is not a duplicate. – chiastic-security Jan 25 '18 at 10:27
  • Note that with shopt -s autocd, .. would be valid. – Stéphane Chazelas Jan 25 '18 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). – Stephen Kitt Jan 25 '18 at 11:03

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'
# ..
| improve this answer | |
  • 2
    No, it’s the command_not_found handling, see the suggested duplicate. – Stephen Kitt Jan 24 '18 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. – chiastic-security Jan 25 '18 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. – Stephen Kitt Jan 25 '18 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). – Stephen Kitt Jan 25 '18 at 9:41

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