[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shell completion on w32 uses "/" instead of "\"
From: |
Lennart Borgman |
Subject: |
Re: Shell completion on w32 uses "/" instead of "\" |
Date: |
Sun, 24 Dec 2006 02:01:27 +0100 |
User-agent: |
Thunderbird 1.5.0.9 (Windows/20061207) |
Kevin Gallagher wrote:
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>.
Yes, you are right. This behaviour is not mirrored at all in Emacs shell.
Now, here's a surprise! Suppose "aa" has a subdirectory "xy" and "xy"
...
I do not think cases outside of what cd is specified to do in cmd.exe
are important.
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 is not specified to work. I found some surprises there too before.
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>.
It would make a very bad impression I think.
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.
Then we will just leave that bug there for a long period. I think that a
combination of long periods between releases and leaving bugs is not so
very good. And unfortunately it is a bug on w32, that in one sense is a
platform where we want to attract people because it makes it easier to
switch to GNU/Linux later.
BTW, I found the directory sync in shell is not working so good for me.
Is there something that prevents that comint sends a pwd and reads the
result before trying to TAB file name expansion?
- Re: Shell completion on w32 uses "/" instead of "\", (continued)
- Re: Shell completion on w32 uses "/" instead of "\", Jason Rumney, 2006/12/21
- Re: Shell completion on w32 uses "/" instead of "\", Chris Moore, 2006/12/22
- Re: Shell completion on w32 uses "/" instead of "\", Eli Zaretskii, 2006/12/22
- Re: Shell completion on w32 uses "/" instead of "\", Chris Moore, 2006/12/22
- Re: Shell completion on w32 uses "/" instead of "\", Lennart Borgman, 2006/12/22
- Re: Shell completion on w32 uses "/" instead of "\", Lennart Borgman, 2006/12/23
- Re: Shell completion on w32 uses "/" instead of "\", Kevin Gallagher, 2006/12/23
- Re: Shell completion on w32 uses "/" instead of "\",
Lennart Borgman <=
- Re: Shell completion on w32 uses "/" instead of "\", Nick Roberts, 2006/12/23
- Re: Shell completion on w32 uses "/" instead of "\", Lennart Borgman, 2006/12/23
- Re: Shell completion on w32 uses "/" instead of "\", Richard Stallman, 2006/12/24
Re: Shell completion on w32 uses "/" instead of "\", LENNART BORGMAN, 2006/12/21