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

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

[Drew Adams]

emacs -Q
 
load library cygwin-mount.el, then setup-cygwin.el:
 
http://www.emacswiki.org/emacs/cygwin-mount.el
http://www.emacswiki.org/emacs/setup-cygwin.el
 
Use /bin/bash.exe as SHELL.
 
Hit `!' on some file.
 
Type the absolute name of an executable file, which name contains a
space. For example: c:/Program Files/Adobe/FrameMaker7.2/FrameMaker.exe.
 
You get an error: /usr/bin/bash: c:/Program: No such file or directory
 
The problem is that the command and its args are not being
shell-quoted, so the file name is truncated at the first space (after
`Program').  The same problem exists for `&' as for `!'.
 
I'm not sure the solution would be as simple as just applying
`shell-quote' to whatever text is entered, since the command is also
supposed to accept some wildcard characters, such as `*'.  (I didn't
check the code - just guessing.)
 
But some fix must be found. Otherwise, `!' and `&' are less than
useful on platforms such as Windows that typically use spaces in file
and directory names.
 
This problem exists in Emacs 22 also. There, there are even more
wildcards to deal with, since `&' is a wildcard for `!'.  For example,
to run `foo' asynchronously, you can enter `foo * &'.
 

In GNU Emacs 23.0.90.1 (i386-mingw-nt5.1.2600)
 of 2009-02-01 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
 

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

[Drew Adams]

I said `shell-quote', but I meant `shell-quote-argument' or
`shell-quote-wildcard-pattern'. I'm not real clear on how to use the latter, or
whether either of them might help here. Trying them on my own didn't seem to
work. The `*' after the command/file input was taken as part of the command/file
name, provoking an error (no such file or directory).

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.

I also forgot to mention in the recipe to do this is in a Dired buffer.

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

[Andreas Schwab]

"Drew Adams" <drew.adams@oracle.com> writes:

> 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.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Drew Adams]

> > 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.

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

[Drew Adams]

> 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.