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
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 character. Compared to
this problem, the handling of the '%' charac
A trivial adjustment to support C++, and to avoid gcc warnings in case
sh-quote.h gets included twice.
2012-05-08 Bruno Haible
sh-quote: Make C++ safe and allow multiple inclusion.
* lib/sh-quote.h: Add double-inclusion guard. For C++, wrap function
declarations in ext
On 05/08/2012 01:05 PM, Niels Möller wrote:
> I think it should work fine to just get the gnutls release and apply
> Paul's patch to the file gnutls-3.0.9/gl/stdint.in.h before running the
> configure script.
Yes, that's the idea. Thanks.
Dagobert Michelsen writes:
> If Paul or you could provide a bootstrapped tarball I'll be happy to test it
> as
> I am not really familiar with gnulib bootstrapping.
I'm also not very familiar with gnulib.
But I think it should work fine to just get the gnutls release and apply
Paul's patch to
Hi Niels,
Am 08.05.2012 um 10:55 schrieb Niels Möller:
> Paul Eggert writes:
>> Thanks. This seems to be a win regardless of whether it
>> fixes the nettle problems,
>
> Dago, can you test if it solves the SunOS-5.9 problem for you? I.e.,
> apply Paul's patch to gnutls/gnulib, then *unapply* th
Jim Meyering wrote:
> Akim Demaille wrote:
...
>> The attached patch enhances warnings.m4 in several ways:
>>
>> - gl_COMPILER_OPTION_IF allows to define more fine grain tests on the
>> behavior of the compiler. Forcing the result to be an assignment to
>> a variable (which is AC_SUBST'ed) doe
Paul Eggert writes:
> Such usage violates the C standard: even if one compiler
> is not picky about it, your're likely to run into another that
> does. So a better solution is needed.
I've committed a workaround to nettle-types.h. It now does
/* Pretend these types always exists. Nettle does
On 05/08/2012 01:55 AM, Niels Möller wrote:
> I'm not sure how picky the compiler is about multiple but equivalent
> typedefs of the same name.
Such usage violates the C standard: even if one compiler
is not picky about it, your're likely to run into another that
does. So a better solution is ne
[adding coreutils, bug-gnulib]
On 05/08/2012 04:48 AM, Akim Demaille wrote:
> This is why bison gets (in my VPATH-build where builddir is two
> levels down inside srcdir):
>
> #line 277 "parse-gram.y"
> #line 2271 "../../../src/parse-gram.c"
>
> with a properly computed relative path, it should
FYI, I've pushed these two patches:
>From a396e729684ec533c504dd3e619f669834821688 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Tue, 8 May 2012 10:55:21 +0200
Subject: [PATCH 1/2] init.sh: don't let bash aliases interfere with tests
* tests/init.sh: Undefine any pre-defined aliases if the s
Hi,
On Fri, May 04, 2012 at 08:20:51AM +0200, Sylvain wrote:
> On Wed, May 02, 2012 at 01:47:06PM +0200, Sylvain wrote:
> > On Wed, May 02, 2012 at 12:43:48PM +0200, Sylvain wrote:
> > I tested the fix under Debian/Hurd. AFAICS it works :)
> >
> > I'll upload a new Debian version of FreeDink wit
Paul Eggert writes:
> Thanks. This seems to be a win regardless of whether it
> fixes the nettle problems,
Dago, can you test if it solves the SunOS-5.9 problem for you? I.e.,
apply Paul's patch to gnutls/gnulib, then *unapply* the nettle
workaround I comitted yesterday, and see if you still ge
Akim Demaille wrote:
> I have submitted this patch several times in this thread (starting at
> http://lists.gnu.org/archive/html/bug-gnulib/2012-04/msg00049.html),
> and for some reason it remains unnoticed, and uncommented. Please let
> me know what is wrong in my approach.
>
> I would like to wr
Hi!
I have submitted this patch several times in this thread (starting at
http://lists.gnu.org/archive/html/bug-gnulib/2012-04/msg00049.html),
and for some reason it remains unnoticed, and uncommented. Please let
me know what is wrong in my approach.
I would like to wrap a Bison 2.5.1 soon, and
Le 8 mai 2012 à 08:50, Jim Meyering a écrit :
> Eric Blake wrote:
> ...
>> Meanwhile, no one ever reviewed my proposed doc patch:
>>
>> https://lists.gnu.org/archive/html/bug-gnulib/2012-04/msg00167.html
>
> Links to mailman-archived messages are hard to read
> the moment they contain a few "@"
22 matches
Mail list logo
