... or cd with any other number of additional periods over two (or, since pr3, over three).

Under Windows 8.1 with an NTFS file system, when the shell is working within a folder other than the root of the drive, shell.resolve("...") returns "current directory + ..." (as opposed to the expected "current directory alone"). It should act in the same manner as shell.resolve(".").

Because fs.exists( shell.resolve( "..." ) ) always (correctly) resolves as true, typing "cd ..." into the command line leads to the shell switching to a non-existant directory (as shell.resolve() brings it to the wrong location). Auto-complete promptly crashes shell when the next character is typed ("Java Exception Thrown: java.lang.NullPointerException").

Ooh, dangerous! I didn't know about the Windows "..." shortcut. I've fixed it by treating "..." as ".." on all platforms.

(Please let me if this works for you when pr3 is released, as I don't have a Windows system to test on)

"..." (or "....", or ".....", or "......", etc...) should act as ".", not "..". As far as I'm aware, only ".." should act as ".." does.

In CMD

In Cygwin with bash (still NTFS filesystem)

In explorer after running touch test in cygwin

Notice how I had to open the directory twice to actually get there, but that it does in fact work.

I have not been able to navigate to that folder in cmd using cd ... or cd .../..., but type ...\test outputs the content of the file.

Seems to me that this is a untested edge case in Windows, and that there are some bugs here and there.

You should either treat "..." as an actual directory, and then make sure to handle the edge cases properly,
or you could strip the occurrence of r"\.\.\.+" all together (or replace with ".", which is how the cd in cmd.exe seem to be working)

Might be worth noting that I am running Windows 7 Ultimate 64bit.

I am not sure of how Java libraries handle this particular edge case.