[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Millis
Subject: Re: [bug-gawk] Percent Signs in External Commands on Windows
Date: Thu, 12 Apr 2012 20:58:08 -0700 (PDT)

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]