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

[Eli Zaretskii]

> Date: Mon, 9 Apr 2012 15:24:12 -0700 (PDT)
> From: David Millis <address@hidden>
> Cc: address@hidden
> 
> > (a) there are differences in handling quoted arguments between the
> > Windows runtime libraries supplied with Windows Vista and later, and
> > the runtime in older Windows versions, like XP;
> Do you know a url where I can read up on that?

Here, for example:

  
http://mingw-users.1079350.n2.nabble.com/Shell-globbing-when-running-MinGW-executables-from-MSYS-Bash-td7126029.html

  
http://connect.microsoft.com/VisualStudio/feedback/details/98756/vs2005-setargv-obj-wildcard-handling-broken

> > (b) there are certain situations where you simply _cannot_ get the
> > desired effect by _any_ reasonable use of quotes, due to misfeatures
> > of how quotes are handled by the Windows APIs and the startup code
> > of programs you invoke via the 'system' function.
> I don't understand how this is different from (a).

(a) says quoting is tricky, (b) says that it is sometimes impossible.
One impossible situation is when you need to pass a single " character
to a program.

> CMD /C WHATEVER would strip the chaff quotes before the external programs 
> could see them (if users add such quotes). There's no burden of escaping 
> inner chars.

Well, you are wrong.  First, CMD doesn't do with quotes what you think
it does, please read the Microsoft documentation about that.  And you
_do_ need to escape inner quotes, because many Windows programs,
certainly those Gawk users will want to invoke via the 'system'
function, will glob the command line as part of their startup, and
that globbing code does remove un-escaped quotes.

> > I'd say, doubling every % will solve 99% of problems. The only problem
> > that will be left is the use of %FOO% where FOO is an existing
> > environment variable. Am I right?
> ... where FOO doesn't begin with a percent, digit, asterisk, tilde (with 
> optional chars), and FOO doesn't follow another variable name (the leading 
> percent would belong to it instead of FOO).

Right, but all of these are related to environment variables.

> Doubling percents everywhere would catch %1's and %word%'s, which is what I 
> stumbled on while gawk was passing urlencoded strings to wget (%20 for 
> spaces, etc). I figured other people might more often deliberately use 
> percents for env vars though. I've never noticed precedent to double percents 
> as a workaround in a language, and since the temp batch mechanism is 
> undocumented, it seemed worth reporting in case it was deemed too unintuitive.

I'm grateful for the report.  The issue is what, if anything, should
be done about that in Gawk.

> Granted, rewriting any original command string with presubstituted values 
> would be cleaner. In my code, I do that anyway...
> #command = "echo %TEMP%";
> command = "echo " ENVIRON["TEMP"];
> if (_execSystemAsCmdBatch == 1) gsub(/%/, "%%", command);
> system(command);

Yes.  The question is, should we advise users to go this way as a
workaround for possible tricky issues with percent signs.

> > the Windows port of GNU Make disregards this issue altogether
> I'm not familiar with make, but doesn't it have the long-standing convention 
> of using $(FOO) for everything, including env vars?

Yes.  But Gawk also has access to environment variables, as you show
above.

> And I have difficulty imagining a scenario where an unintended percent would 
> sneak into a filename or compiler/archiver args, so it's not surprising 
> make's doing okay.

Then why wouldn't Gawk do fine as well?

> Sorry for the drawn-out topic. Gawk's my favorite scripting language 
> (cross-platform, standalone exe, regex, and no compiling).

Mine too.

> Btw, is it tricky to compile/cross-compile it for mingw?

Not tricky at all, just copy a few files, including a ready Makefile,
from a subdirectory, and type "make mingw32".  That's it.  There are
instructions in README_d/README_pc file, and just typing "make" after
copying the above-mentioned files will show you the list of Make
targets, some of them relevant to MinGW.