bug#2536: 23.0.90; ! in Dired does not shell-quote the command name and args

["Drew Adams" <drew.adams@oracle.com>]

> From: Drew Adams Sent: Monday, March 02, 2009 7:15 AM
> > > In sum, I don't have any insight about what fix is needed, 
> > > but there is definitely a problem, at least for MS Windows,
> > > where spaces in file names are common.
> > 
> > If you want to use shell meta characters on the command line 
> > it is your own responsibility to add proper quoting.
> > Note that file name completion
> > (ie. minibuffer-complete-shell-command) will DTRT here.
> 
> Yes, I realized after I sent the report that there is no way 
> for Emacs to distinguish a file name with spaces from separate
> arguments. You can close this bug, I guess.

Actually, no, file name completion does *not* DTRT here.
Similarly, for `&' and `M-!'.

c:/Prog TAB will correctly complete to c:/Program Files/ - yes.
But c:/Program Files/ad TAB will *not* complete to
c:/Program Files/Adobe/, and so on.

You cannot use completion to get the shell command (program)
c:/Program Files/Adobe/Framemaker7.2/FrameMaker.exe.  And you
cannot even complete c:/Program  (with a trailing space) to
c:/Program Files/.  The shell thinks the executable is just
c:/Program, and it tries to complete local file names as
shell arguments to pass to that program.

And anyway, if you could complete to the executable
c:/Program Files/Adobe/Framemaker7.2/FrameMaker.exe, then bash
would just complain that there is no such file: c:/Program,
just as it does if you type all of that in and hit RET.

Again, I'm not sure what the ideal solution is. It's true that there is no way
to automatically tell in all cases whether a space separates arguments or is
part of a file name. 

But the existing file-name completion is in any case a bit brain-dead. 

It knows that c:/Prog completes to c:/Program Files/, but it doesn't know to
complete c:/Program Files/ad to c:/Program Files/Adobe.  And in such a case
there is *no ambiguity* over embedded spaces vs argument separators.  There's
nothing tricky happening here, in theory.

The problem is that during completion of c:/Prog Emacs knows that this is a file
name with a space, but as soon as you type ad TAB, it forgets that previous
knowledge and thinks you are trying to complete an argument Files/ad, to be
passed to command c:/Program.  Silly.

The file-name completion could be made more robust. The only potential problem
occurs when there is true ambiguity between an existing file name, with spaces,
and an existing file name whose name is a prefix up to a space.  For example, if
both a directory c:/Program Files/ and an executable c:/Program exist, then it's
not clear whether the space after c:/Program is embedded in a file name or
separates the command name from an argument.

If priority were always given to the longer prefix in such a case, then `!',
`&', and `M-!' would be much more usable. Then, Emacs would not try to look at
Files/ad as a potential argument.

In the uncommon case of true ambiguity (e.g. both dir c:/Program Files/ and
executable c:/Program), a user could anyway manually add quote marks as needed -
as s?he *must* do now in all cases where there are spaces in file names.