You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of 79a9de5 double quote handling in dcrt0.ccbuild_argv () is inconsistent when MSYS=noglob is used.
If winshell is set, only backslash characters are skipped. However, noglob causes quoted () to jump to (any) next double quote character. This is not good, as there might be escaped double quotes in the path, which should be skipped when looking for the next (unescaped) double quote.
build_argv () is also called when launched via strace, which complicates debugging this issue. This issue is also present when new processes are created via CreateProcessA and/or CreateProcessW API in similar circumstances.
noglob is required, if the application would like to use command line arguments longer than 8192 characters and the command line includes any of the following characters: ?*["'(){} (note that both single and double quote characters are included meaning that glob () code is typically hit for shell one-liners). This is because glob () truncates the input, when making Unicode conversion for the pattern. For some reason (perhaps chicked and egg type problem), the buffer is not allocated from heap, but from stack, and this is why the limit is so low.
Nevertheless, if build_argv () is to be called, but glob isn't set, there appears to be no method to pass a double quotes to the application. Consider the following example application:
When executed inside a typical shell. I presume this works because the shell uses spawn () or fork () and exec (), as unless winshell is set, the quoting behavior is similar to noglob being currently set.
# MSYS=noglob ./dump.exe "\"\\\"hello, world\\\", said quoteception\""
``<...>\dump.exe "\"\\\"hello, world\\\", said quoteception\""''.
0: `./dump', length = 6
1: `"\"hello, world\", said quoteception"', length = 37
So far so good. However, pass thru strace to trigger build_argv (). The same effect can be archieved by executing the application directly from Windows, command prompt etc.
Hi.
As of 79a9de5 double quote handling in dcrt0.cc
build_argv ()
is inconsistent whenMSYS=noglob
is used.If
winshell
is set, only backslash characters are skipped. However,noglob
causesquoted ()
to jump to (any) next double quote character. This is not good, as there might be escaped double quotes in the path, which should be skipped when looking for the next (unescaped) double quote.msys2-runtime/winsup/cygwin/dcrt0.cc
Lines 162 to 169 in 79a9de5
build_argv ()
is also called when launched viastrace
, which complicates debugging this issue. This issue is also present when new processes are created viaCreateProcessA
and/orCreateProcessW
API in similar circumstances.noglob
is required, if the application would like to use command line arguments longer than 8192 characters and the command line includes any of the following characters:?*["'(){}
(note that both single and double quote characters are included meaning thatglob ()
code is typically hit for shell one-liners). This is becauseglob ()
truncates the input, when making Unicode conversion for the pattern. For some reason (perhaps chicked and egg type problem), the buffer is not allocated from heap, but from stack, and this is why the limit is so low.Nevertheless, if
build_argv ()
is to be called, butglob
isn't set, there appears to be no method to pass a double quotes to the application. Consider the following example application:When executed inside a typical shell. I presume this works because the shell uses
spawn ()
orfork ()
andexec ()
, as unlesswinshell
is set, the quoting behavior is similar tonoglob
being currently set.So far so good. However, pass thru
strace
to triggerbuild_argv ()
. The same effect can be archieved by executing the application directly from Windows, command prompt etc.The double quotes are now gone, meaning that the application (e.g. shell script) will not likely work as expected.
The text was updated successfully, but these errors were encountered: