On 12 Jul 2016 21:38, Chet Ramey wrote:
> +== CHANGES ==+
> This document details the changes between this version, bash-4.4-beta2, and
> the previous version, bash-4.4-rc1.
why back to beta ? generally "rc" is considered newer than "beta",
and the previous bash-4.4 releases were
1. My target was x86-64, using the master 4.3.30 version of bash
(Sorry for lacking the information)
2. I used the master version of bash on the unicode3.sub before
I will test it for the devel version of bash as soon as.
//dengke
On 2016年08月10日 19:10, Chet Ramey wrote:
On 8/10/16 2:42
---
lib/readline/histexpand.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/readline/histexpand.c b/lib/readline/histexpand.c
index 46a99aa62e30..13248db83048 100644
--- a/lib/readline/histexpand.c
+++ b/lib/readline/histexpand.c
@@ -26,6 +26,7 @@
#endif
#include
+#include
#if d
On 8/11/16 4:54 AM, Mike Frysinger wrote:
> On 12 Jul 2016 21:38, Chet Ramey wrote:
>> +== CHANGES ==+
>> This document details the changes between this version, bash-4.4-beta2, and
>> the previous version, bash-4.4-rc1.
>
> why back to beta ? generally "rc" is considered newer th
On 8/10/16 5:38 PM, Dmitry Goncharov wrote:
>> > does "If any file argument to one of the primaries is of the form
>
>> > /dev/fd/n, then file descriptor n is checked.".
>
>
>> It seems like a documentation error.
>
> What should the man page say instead?
Probably something close to what the
On 8/11/16 5:52 AM, Mike Frysinger wrote:
> ---
> lib/readline/histexpand.c | 1 +
> 1 file changed, 1 insertion(+)
Thanks for the fix.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@
simple code to reproduce:
bash -c 'v=$*'
gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
quote_string (string=0x0) at subst.c:3940
3940 if (*string == 0)
#0 quote_string (string=0x0) at subst.c:3940
#1 0x0045c052 in param_expand (string=string@entry=0x723
These variables are located on the stack and are never read/written
directly by bash. Instead, they're all accessed indirectly via the
POSIX signal API. Since POSIX does not require volatile, and bash
itself doesn't require volatile, drop the volatile markings. If we
don't, you get a lot of warn
Noticed when looking into segfault. The "discarding const qualifier"
warning always makes me worried as it tends to come from bad code.
---
arrayfunc.c | 18 ++
arrayfunc.h | 12 ++--
2 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arrayfunc.c b/arrayfunc.
On systems where sizeof(void*) != sizeof(unsigned int) (e.g. on most
64-bit platforms), we get a warning like so:
tmpfile.c: In function 'sh_seedrand':
tmpfile.c:128:61: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
srandom (tv.tv_sec ^ tv.tv_usec ^ (getpid
Noticed when looking into segfault. The "discarding const qualifier"
warning always makes me worried as it tends to come from bad code.
---
general.c | 26 +-
general.h | 18 +-
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/general.c b/ge
Noticed when looking into segfault. The "discarding const qualifier"
warning always makes me worried as it tends to come from bad code.
---
externs.h| 2 +-
lib/glob/glob.c | 2 +-
lib/sh/eaccess.c | 10 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/externs.
On 8/11/16 8:29 AM, Mike Frysinger wrote:
> simple code to reproduce:
> bash -c 'v=$*'
http://lists.gnu.org/archive/html/bug-bash/2016-07/msg00066.html
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech
On 11 Aug 2016 08:32, Chet Ramey wrote:
> On 8/11/16 8:29 AM, Mike Frysinger wrote:
> > simple code to reproduce:
> > bash -c 'v=$*'
>
> http://lists.gnu.org/archive/html/bug-bash/2016-07/msg00066.html
thanks ... still catching up after vacation and hadn't made it that far yet ;)
-mike
sign
On 8/11/16 8:30 AM, Mike Frysinger wrote:
> These variables are located on the stack and are never read/written
> directly by bash. Instead, they're all accessed indirectly via the
> POSIX signal API. Since POSIX does not require volatile, and bash
> itself doesn't require volatile, drop the vola
On 11 Aug 2016 11:45, Chet Ramey wrote:
> On 8/11/16 8:30 AM, Mike Frysinger wrote:
> > These variables are located on the stack and are never read/written
> > directly by bash. Instead, they're all accessed indirectly via the
> > POSIX signal API. Since POSIX does not require volatile, and bash
On 8/11/16 12:12 PM, Mike Frysinger wrote:
> On 11 Aug 2016 11:45, Chet Ramey wrote:
>> On 8/11/16 8:30 AM, Mike Frysinger wrote:
>>> These variables are located on the stack and are never read/written
>>> directly by bash. Instead, they're all accessed indirectly via the
>>> POSIX signal API. Si
Hi,
since we already allow circular refs in the variable_context, the below
answers your request. It means: in the function scope the name references to
existing global variables will be correctly resolved. Please note that using
find_global_variable in global_variable=find_global_variable(new
Hi,
amending the previous approach; please find the attached patch: the global
namerefs are followed, and resolved in the function scope. It works as follows:
bash-4.4$ typeset -n v=w; typeset -n w=x; typeset -n x=v; x=4
bash: warning: x: circular name reference.
bash-4.4$ declare -n ref="HOME
On 8/11/16 5:10 PM, Piotr Grzybowski wrote:
> I personally believe that we should make this change (of course not before
> 4.4 ;-)), and that it should follow the global nameref chain.
> The patch (not breaking the test suite) follows.
The problem with this fix, and part of what makes the situ
20 matches
Mail list logo
