Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I unfortunately need to work with cmd.exe from time to time and it usually doesn't bug me too much except when I am editing a file in vim and then try to run that file with tab-completion.

If I have the file open in vim, also exists in the directory. The behavior I see is:

C:\foo> f[TAB]

This is rather infuriating and I'm wondering if there is any way to prevent this behavior short of a complete workaround like changing my swap file naming or using PowerShell. I did notice PowerShell does not emulate this behavior, but I really don't want to use it.

share|improve this question
Why are you so opposed to using PowerShell? – Sasha Chedygov Sep 13 '10 at 0:22
I found it less useful than helpful... It's counter-intuitive to both cmd.exe and bash. – djs Sep 19 '10 at 0:35
There is now an excellent solution to this problem: clink provides bash readline functionality in a native cmd.exe window. – djs May 1 '13 at 4:36
up vote 3 down vote accepted

Windows is behaving exactly as you'd expect if you think it through (and to be honest, until seeing your question, I hadn't thought it completely through). A file name that begins with a '.' is seen as a file with a null file name with an extension. To see how this works, create a directory and then create the following files using touch (I'm assuming you're familiar with touch):

touch .b.bbb
touch b.bbb

Now, in that directory, use the tab key to cyle through the files and you'll see that the sequence is:

If you want to go through the 'a' files, then type 'a' before the tab and you'll get a predictable,

As for the _ character in a file name, it's just like any other character and sorts after 'Z'.

share|improve this answer

The semantics of FindFirstFile (what CMD uses to enumerate matching files) means that the pattern is tested against the long file name (what you'd like to see) as well as against the autogenerated "8.3" file name. The short name generation is what is causing your spurious matches.

You can disable 8.3 generation via FSUTIL, but that stops FURTHER generation and doesn't remove already existing names. You'd have to run a script that would do renames to fully remove them.

This is dangerous, however, since some programs are clueless and will write the autogenerated shortnames down (say you are using a 16-bit installer, like old versions of MSOFFICE). If you disable their generation, then these installers may fail.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .