Re: [bug-gawk] Percent Signs in External Commands on Windows

[David Millis]

--- On Thu, 4/12/12, Eli Zaretskii <address@hidden> wrote:

> > You protect your first and last quotes, buy _adding_
> > quotes whose sole purpose are to get eaten by CMD's stupid
> > but predictable heuristic.
> > There's no inner-escaping to worry about, and the
> > command string is otherwise unscathed.
> 
> You are using toy examples.  It doesn't work in real
> life.  E.g., outer quotes are only removed if the whole
> command starts with a quote, which is not always what you
> want (think about protecting a wildcard).
> 
> [...] It's unworkable.

I used a toy example only for the aside about escaping characters meant to pe 
passed INTO an external program's arg, since you brought it up.

This is not relevant to CMD /C "...". CMD does not glob its own args as other 
programs would. When a user wraps extra quotes around the command string, the 
command is _guaranteed_ to start with the quote, to it always gets removed. No 
unescaping happens during the unwrapping. CMD then parses the unwrapped command 
string.


The following:

wgetCmd = "\"path\\wget.exe\"";  # path may or may not begin with a quote
# ...
command = wgetCmd " \"" url "\"";
command = "\"" command "\"";  # user-added quotes, definitely removed
system(command);

Is not a toy example, and it illustrates real-world application of fodder 
quotes having _no_ impact on the content they surround. The string, prior to 
concatenation, executes exactly as if it had been written at a live prompt.
I've done this with wget, curl, spidermonkey, xmlstarlet, ffmpeg, imagemagick, 
uftp, and the commandline versions of MsSQL and Wireshark. I've never seen 
signs that CMD does anything to the /C string it's given other than remove two 
doomed quotes.

Wildcards within individual args are _irrelevant_ when comparing batch files to 
cmd /c. Neither handles those better or worse.
It's not like bash -c "string that needs extra escaping".


David Millis