> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Fri, 11 May 2012 11:28:17 +0200
>
> Since '^' is a quoting character in cmd.exe, maybe you can try whether
> it helps to protect "*" inside double-quotes on Windows 7? That is,
> try to pass arguments such as
> ^*
> ^^*
> "*"
> "^*"
>
Eli Zaretskii wrote:
> I'd suggest something along these lines in the comments:
>
> Note that if strings quoted by this module are to be passed to
> 'system' or 'popen' and include wildcards, they need to be processed
> by 'glob' before quoting, to get the wildcards expanded rather than
>
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Sat, 12 May 2012 11:36:28 +0200
>
> >
> > http://answers.microsoft.com/en-us/windows/forum/windows_7-files/is-this-a-known-problem-with-windows-wildcard/fbd381a5-bb80-e011-9b4b-68b599b31bf5
>
> Oh really. When I tried to list all files tha
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Sat, 12 May 2012 11:31 +0200
>
> Eli Zaretskii wrote:
> > If programs need to call 'glob' before calling 'system' and 'popen'
> > with arguments quoted by this module, that fact should be prominently
> > mentioned in the documentation.
>
> Th
Eli Zaretskii wrote:
> there's another subtlety in Windows globbing of wildcards: it
> matches both the "normal" file names and their 8+3 aliases.
> Therefore, "" (8 ? characters) will match every file without
> an extension, and ".???" will match all the files. But
> perhaps the m
Eli Zaretskii wrote:
> If programs need to call 'glob' before calling 'system' and 'popen'
> with arguments quoted by this module, that fact should be prominently
> mentioned in the documentation.
The programmer needs to invoke glob explicitly if he uses the system-quote
module *and* wants wildcar
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Fri, 11 May 2012 11:28:17 +0200
>
> Since '^' is a quoting character in cmd.exe, maybe you can try whether
> it helps to protect "*" inside double-quotes on Windows 7? That is,
> try to pass arguments such as
> ^*
> ^^*
> "*"
> "^*"
>
Eli Zaretskii wrote:
> > The wildcard expansion between GetCommandLine() and argv has been
> > changed to consider '*' inside double-quotes as a wildcard.
> >
> > Any idea what gnulib can do against it?
> ...
> I know of nothing simpler, if you want to support environments other
> than MinGW.
Sin
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Fri, 11 May 2012 01:42:20 +0200
>
> expected: ???
> received: sys
> expected:
> received: sys
> expected: ?
> received: sys
> for input = |???|: CreateProcess() command failed with status 1:
> .\test-system-quote-child.exe ???
> for
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Fri, 11 May 2012 01:58:02 +0200
>
> > If I'm not missing anything, I submit that '*' should be removed from
> > the list of special characters. Leaving it there means that it will
> > be impossible to invoke programs with arguments that inclu
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Fri, 11 May 2012 02:08:43 +0200
>
> Thanks a lot for doing this testing. Yes, it is consistent with what you
> said: The wildcard expansion between GetCommandLine() and argv has been
> changed to consider '*' inside double-quotes as a wildcard
Eli Zaretskii wrote:
> > $ ./configure (with the appropriate options for mingw, depending on your
> > environment)
> > $ make
> > $ make check
> > or (for just the single test)
> > $ cd gltests
> > $ make check TESTS=test-system-quote.sh
>
> As expected, it fails on Wi
Paul Eggert wrote:
> In the context of 'diff' we don't want "*" to be a wildcard;
> we want it to be just a literal "*".
Your statement holds not only in the context of 'diff', but also in the
context of any program that uses gnulib. Because gnulib is about implementing
POSIX semantics on weird sy
Hi Eli,
> > If you want to see what happens, just remove the '*' from
> > SHELL_SPECIAL_CHARS and re-run the unit test.
>
> I see this:
>
> for input = |*|: CreateProcess() command failed with status 3:
> .\test-system-quote-child.exe *
>
> But IIUC that just means we hit this condition in t
I replied to Eli:
> Eli Zaretskii wrote:
> > > The test suite of the module 'system-quote' reveals that the '*' is also
> > > special for CreateProcess on Windows and needs to be escaped
> >
> > What about '?'? Should we quote it as well?
>
> The statements that I have in the unit test
>
>
Bastien ROUCARIES wrote:
> Or cmd /v:on but it will work only with xp and latter
>
> ok we should use delayed expansion but we should in this case escape !
>
> try cmd /v /c printf "%s\n" foo!CR!bar' | od -t x1
Delayed expansion is not enabled by default, AFAICS.
And system() and popen() don't p
> Date: Thu, 10 May 2012 09:28:38 -0700
> From: Paul Eggert
> CC: Bruno Haible , bug-gnulib@gnu.org
>
> On 05/10/2012 09:20 AM, Eli Zaretskii wrote:
> > If I'm not missing anything, I submit that '*' should be removed from
> > the list of special characters. Leaving it there means that it will
>
On 05/10/2012 09:20 AM, Eli Zaretskii wrote:
> If I'm not missing anything, I submit that '*' should be removed from
> the list of special characters. Leaving it there means that it will
> be impossible to invoke programs with arguments that include
> wildcards.
In the context of 'diff' we don't
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Thu, 10 May 2012 11:29:17 +0200
>
> > > If I recall it correctly, the
> > > check_one (interpreter, prog, "*");
> > > case failed: Apparently, when you pass a single unquoted '*' argument
> > > to CreateProcess, it can fail with GetLastError
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Thu, 10 May 2012 00:35:08 +0200
>
> $ ./configure (with the appropriate options for mingw, depending on your
> environment)
> $ make
> $ make check
> or (for just the single test)
> $ cd gltests
> $ make check TEST
Or cmd /v:on but it will work only with xp and latter
ok we should use delayed expansion but we should in this case escape !
try cmd /v /c printf "%s\n" foo!CR!bar' | od -t x1
see http://stackoverflow.com/a/4095133 for order of extension
On Thu, May 10, 2012 at 2:06 PM, Bruno Haible wrote:
>
Bastien ROUCARIES wrote:
> Something like this
>
> ^^^%NL%%NL%^%NL%%CR%
No, this does not work either.
$ export NL='
'
$ eval `echo "export CR='_'" | tr '_' '\r'`
$ echo "$NL" | od -t x1
000 0a 0a
002
$ echo "$CR" | od -t x1
000 0d 0a
002
$ cmd.exe /c 'printf "%s\n" foo^%NL%
Hi Paul,
> > shell_quote_argv and system_quote_argv are essentially the same
> > function, differing only in that one invokes
> > shell_quote_length/shell_quote_copy and the other calls
> > system_quote_length/system_quote_copy. Perhaps they should be
> > refactored into calling a single function
No you need to escape new one the cr
Something like this
^^^%NL%%NL%^%NL%%CR%
Bastien
Le 10 mai 2012 00:41, "Eric Blake" a écrit :
On 05/09/2012 04:08 PM, Bruno Haible wrote:
> Bastien ROUCARIES wrote:
>> Something like this will w...
If I understood that page, the magic sequence is '^-newlin
echo line1^
line2
Work also and could be simple
Maybe
echo line1^
\rline2
Will work with \r a not escaped carriage return
Le 10 mai 2012 00:07, "Bruno Haible" a écrit :
Bastien ROUCARIES wrote:
> Something like this will work
> http://stackoverflow.com/a/269819
Indeed! It allows to substitu
Eli,
> > If I recall it correctly, the
> > check_one (interpreter, prog, "*");
> > case failed: Apparently, when you pass a single unquoted '*' argument
> > to CreateProcess, it can fail with GetLastError() = ERROR_PATH_NOT_FOUND.
>
> That is expected and reasonable: the first token in the argu
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Thu, 10 May 2012 00:35:08 +0200
>
> > Which calls to CreateProcess that used '*' failed? You aren't saying
> > that the second argument to CreateProcess cannot include unquoted '*'
> > characters, are you?
>
> If I recall it correctly, the
>
Eric Blake wrote:
> Can you use: ^%NL%%CR% to get carriage-return?
No. None of the combinations with up to 3 occurrences of %NL% and %CR%
produces a 0x0d byte in the output.
Bruno
On 05/09/2012 04:08 PM, Bruno Haible wrote:
> Bastien ROUCARIES wrote:
>> Something like this will work
>> http://stackoverflow.com/a/269819
>
> Indeed! It allows to substitute newlines.
>
> $ export NL='
> '
> $ cmd.exe /c 'printf "%s\n" foo^%NL%%NL%bar' | od -t x1
> 000 66 6f 6f 0a 62 61 72
Eli,
> Which calls to CreateProcess that used '*' failed? You aren't saying
> that the second argument to CreateProcess cannot include unquoted '*'
> characters, are you?
If I recall it correctly, the
check_one (interpreter, prog, "*");
case failed: Apparently, when you pass a single unquoted
Bastien ROUCARIES wrote:
> Something like this will work
> http://stackoverflow.com/a/269819
Indeed! It allows to substitute newlines.
$ export NL='
'
$ cmd.exe /c 'printf "%s\n" foo^%NL%%NL%bar' | od -t x1
000 66 6f 6f 0a 62 61 72 0a
010
But I don't succeed in getting a carriage-return
Hi Paul,
> Shouldn't that be system_quote_length (interpreter, string) + 1?
Oops, corrected.
> > # define CMD_FORBIDDEN_CHARS "\n\r"
>
> That macro is never used -- is that intended?
I'm not sure what to do with strings that contain such characters.
Surely, rejecting them would be better than
> Date: Tue, 08 May 2012 23:23:02 -0700
> From: Paul Eggert
> CC: br...@clisp.org, bug-gnulib@gnu.org
>
> On 05/08/2012 10:46 PM, Eli Zaretskii wrote:
> > Can you be more specific in your question? Are you asking whether any
> > byte stream is allowed in the command-line arguments?
>
> The basi
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Wed, 09 May 2012 11:20:56 +0200
>
> Eli Zaretskii wrote:
> > > The test suite of the module 'system-quote' reveals that the '*' is also
> > > special for CreateProcess on Windows and needs to be escaped
> >
> > What about '?'? Should we quot
On Wed, May 9, 2012 at 11:23 AM, Bruno Haible wrote:
> Eli Zaretskii wrote:
>> > Is there any chance that putting a newline or CR in an
>> > environment variable, then using %varname%, would allow one to
>> > embed such a character?
>>
>> Not surprisingly, it doesn't work, at least in my testing.
On Wed, May 9, 2012 at 3:37 AM, Bruno Haible wrote:
> This is the module 'system-quote'.
>
> It turns out that on native Windows, when going through cmd.exe, it is
> not possible to pass arguments that contains a newline ('\n') or a CR ('\r')
> character: the command gets truncated at such a chara
Eli Zaretskii wrote:
> > Is there any chance that putting a newline or CR in an
> > environment variable, then using %varname%, would allow one to
> > embed such a character?
>
> Not surprisingly, it doesn't work, at least in my testing.
Yup, that's what I found out as well. In a Cygwin shell I d
Eli Zaretskii wrote:
> > The test suite of the module 'system-quote' reveals that the '*' is also
> > special for CreateProcess on Windows and needs to be escaped
>
> What about '?'? Should we quote it as well?
The statements that I have in the unit test
check_one (interpreter, prog, "?");
On 05/08/2012 10:46 PM, Eli Zaretskii wrote:
Can you be more specific in your question? Are you asking whether any
byte stream is allowed in the command-line arguments?
The basic idea is that we're trying to emulate a function
like execvp, which takes an array of C strings and which
does not c
> Date: Tue, 08 May 2012 21:18:17 -0700
> From: Paul Eggert
> CC: Eli Zaretskii , bug-gnulib@gnu.org
>
> Are there restrictions about what can go into the strings?
> For example, can they contain UTF-8 encoding errors?
Can you be more specific in your question? Are you asking whether any
byte s
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org
> Date: Wed, 09 May 2012 03:43:22 +0200
>
> The test suite of the module 'system-quote' reveals that the '*' is also
> special for CreateProcess on Windows and needs to be escaped
What about '?'? Should we quote it as well?
Btw, the issue of quotin
> From: Ben Pfaff
> Cc: Eli Zaretskii , bug-gnulib@gnu.org
> Date: Tue, 08 May 2012 21:03:34 -0700
>
> Bruno Haible writes:
>
> > It turns out that on native Windows, when going through cmd.exe, it is
> > not possible to pass arguments that contains a newline ('\n') or a CR ('\r')
> > characte
Thanks for working on this. Some comments:
/* Copies the quoted string to p and returns the incremented p.
There must be room for shell_quote_length (string) + 1 bytes at p. */
Shouldn't that be system_quote_length (interpreter, string) + 1?
# define CMD_FORBIDDEN_CHARS "\n\r"
That ma
Bruno Haible writes:
> It turns out that on native Windows, when going through cmd.exe, it is
> not possible to pass arguments that contains a newline ('\n') or a CR ('\r')
> character: the command gets truncated at such a character. Compared to
> this problem, the handling of the '%' character i
The test suite of the module 'system-quote' reveals that the '*' is also
special for CreateProcess on Windows and needs to be escaped, otherwise
CreateProcess may fail (at least on Windows XP).
Therefore, the 'execute' and 'spawn-pipe' modules need a fix.
2012-05-08 Bruno Haible
exec
s problem, the handling of the '%' character is easy.
2012-05-08 Bruno Haible
New module 'system-quote'.
* lib/system-quote.h: New file.
* lib/system-quote.c: New file.
* modules/system-quote: New file.
= lib/system-quot
46 matches
Mail list logo
