Re: Shell completion on w32 uses "/" instead of "\"

[Kevin Gallagher]

I just got finished reading through this thread and, I must say, I'm a bit puzzled by its continued limited focus to the question of "To backward slash or not to backward slash?" in an Emacs shell window running cmd.exe (or equivalent) on w32.  Instead, this discussion would benefit greatly by taking several steps backward and looking at the overall command line behavior in cmd.exe, with the goal of devising an overall strategy for Emacs.  There is a need to determine to what extent should Emacs support cmd.exe syntax and behavior in its support for running cmd.exe in a shell window.

So, let's take a look at some of the cmd.exe input syntax.  Some it is is rather strange, by the way, and some of it is quite unexpected.  For example, sometimes delimiters are needed between a command and the first parameter, but other times they are not needed.  For example, ">cd ..", with a space delimiter, and   ">cd..", without a space delimiter are both accepted by the parser as valid.  Press return and both are move the current directory up one level.  However, enter ">cd." followed by a <TAB> and the bell rings, even though ">cd.." is valid.

Suppose the current directory contains 5 directory entries called "aa", "bb", "cc", "dd one", and "eleven ee".  Enter "cd" at prompt and then press <TAB>, the bell rings.  Enter "cd", followed by a space, and then press <TAB>, the first directory, in the current directory, is displayed next to "cd" like this:

cd aa

Press <TAB> again and the line is re-written as

cd bb

<TAB> again and we have

cd cc

again,

cd "dd one"

again,

cd "eleven ee"

and again,

cd aa

cycling back through the list.  It makes no attempt to continue command completion into a subdirectory.  To make this happen, the user must enter a backward slash after the directory name and then press <TAB>.

Now, here's a surprise!  Suppose "aa" has a subdirectory "xy" and "xy" has a subdirectory "zz".  Suppose the current directory is "kg" on drive E.  The the prompt looks like this:

E:\kg>

Suppose I enter the cd command like this:

E:\kg>cd aa/xy/zz

(Note I am using forward slashes.)  When Enter is pressed, you might think cmd.exe would report an error.  It does not. It changes the directory AS IF backward slashes had been entered!  The prompt returned is

E:\kg\aa\xy\zz>

This behavior is quite strange.  Now let's look at the "dir" command.  We already know that

E:\kg\aa>dir xy/zz

yields

Invalid switch - "zz"

but not always!  In some circumstances, it will yield

Parameter format not correct - "zz"

Nevertheless, if, instead, I wrap the parameter input to "dir" in double quotes like this

E:\kg\aa>dir "xy/zz"

then cmd.exe accepts this and generates a directory listing of "E:\kg\aa\xy\zz"!

This leads me to suggest that, instead of "To backward slash or not to backward slash?", perhaps the question should be "To double quote or not to double quote?"  Of course, we have to remember that this applies to "dir" but not "cd", though "cd" will accept the double quotes.  I haven't tested this syntax with other commands, such as "copy", "xcopy", etc.  But, hopefully, you get the point:  cmd.exe has a very strange input syntax parser with unexpected and inconsistent behavior in what it is willing to accept as valid input syntax.

The behavior of cmd.exe, when <TAB> is pressed, is quite different from what Emacs attempts to do for the user.  Technically, one could argue that, for cmd.exe, Emacs should append nothing to a directory completed by <TAB>. 

I think I've made the case that the support Emacs should provide when running cmd.exe in a shell window is complicated and very messy; too messy to deal with now.  I vote we let it be until after Emacs 22 is released.