On 10.08.2015 22:19, Chet Ramey wrote:
On 8/9/15 1:37 PM, aixtools wrote:
Hi,
Via google I came across the define named
config-top.h:/* #define SYSLOG_HISTORY */
Changing it (manually) to
config-top.h:#define SYSLOG_HISTORY
Adds syslog statements such as:
Aug 9 16:52:55 x064 user:info syslo
$ export LC_ALL=en_US.UTF-8
$ valgrind --leak-check=full /bin/bash -c 'exit 0'
#
==4190== HEAP SUMMARY:
==4190== in use at exit: 22,269 bytes in 614 blocks
==4190== total heap usage: 698 allocs, 84 frees, 29,706 bytes allocated
==4190==
==4190== 12 bytes in 1 blocks are definitely lost in lo
Hi,
devel branch's commit 67440b introduced a change in sig.c; specifically,
deleting line 608
seems to solve the problem (though I've no idea what else it breaks).
reproducer:
PS1="$PS1\$(true)" # command substitution in PS1 seems to be important to
reproduce
wait
^C
# end of reproducer
Th
reproducer:
cd ~
mkdir MYDIR
cd MYDIR
echo "${PWD/#$HOME/~}"
Result of echo in 4.3:
/home//MYDIR
Result of echo in 4.2:
~/MYDIR
Is tilde expansion in 4.3 supposed to happen? I don't see any mention in
4.3's compat file, apart from
point 20 which was already present in COMPAT files for older v
id=1087010
From 25c9e25078d2b7b8667d76e53173811e8f497ed0 Mon Sep 17 00:00:00 2001
From: Ondrej Oprala
Date: Mon, 4 Aug 2014 10:21:26 +0200
Subject: [PATCH] check for need_here_doc >0
---
eval.c | 2 +-
parse.y | 10 +-
y.tab.c | 10 +-
3 files changed, 11 insertions(+), 11 delet
On 06/11/2014 07:26 PM, Chet Ramey wrote:
On 6/11/14, 6:35 AM, Ondrej Oprala wrote:
Hi,
bash-4.3 seems to act differently(better) in vi visual mode, than previous
bash-4 minors.
However, ksh gave a different result all along.
This isn't standardized, so I'm not worried about small d
shopt -s compat42 seems to actually set compat41, also leading
shopt to report that both compat 41 and 42 are on.
Thanks,
Ondrej
diff --git a/builtins/shopt.def b/builtins/shopt.def
index 55d4543..80e257d 100644
--- a/builtins/shopt.def
+++ b/builtins/shopt.def
@@ -160,7 +160,7 @@ static struct {
Hi,
bash-4.3 seems to act differently(better) in vi visual mode, than
previous bash-4 minors.
However, ksh gave a different result all along.
Steps to reproduce:
1. set -o vi
2. meta+k
3. v
4. for i in $(seq 10); do j=$( echo $i$i ); echo $j; done
echo second
# save and close the editor
Results
On 05/23/2014 05:05 PM, Dan Douglas wrote:
On Friday, May 23, 2014 10:48:11 AM Chet Ramey wrote:
On 5/23/14, 10:17 AM, Ondrej Oprala wrote:
Hi, there've recently been a few bug reports against bash on RH BZ,
saying that bash can't handle infinite recursion the way zsh or ksh can.
On 05/23/2014 04:48 PM, Chet Ramey wrote:
On 5/23/14, 10:17 AM, Ondrej Oprala wrote:
Hi, there've recently been a few bug reports against bash on RH BZ,
saying that bash can't handle infinite recursion the way zsh or ksh can.
Looking at execute_cmd.c, there are the funcnest{,_max}
Hi, there've recently been a few bug reports against bash on RH BZ,
saying that bash can't handle infinite recursion the way zsh or ksh can.
Looking at execute_cmd.c, there are the funcnest{,_max} variables
and a piece of code using them in execute_function().
Will funcnest_max be set to non-0
On 04/01/2014 10:03 PM, Chet Ramey wrote:
On 4/1/14 1:36 PM, Ondrej Oprala wrote:
That's possible. It might also have been an attempt at further optimization
- just calling malloc if pointer == NULL, instead going through an
additional realloc call.
Either way, I find both of these
On 04/01/2014 08:21 PM, Eric Blake wrote:
On 04/01/2014 11:36 AM, Ondrej Oprala wrote:
Bruno Haible argued that the cost of a redundant if conditional is
cheaper than the cost of a function call in profiling runs, at least in
the portions of gnulib where he used that idiom. Personally, I like
On 04/01/2014 05:43 PM, Eric Blake wrote:
On 04/01/2014 09:28 AM, Ondrej Oprala wrote:
Hi,
Could someone please explain to me, why are xrealloc and xfree (or more
specifically - their parts) from lib/malloc/xmalloc.c necessary?
e.g.
if (string)
free(string);
Why is this needed? AFAIK
Hi,
Could someone please explain to me, why are xrealloc and xfree (or
more specifically - their parts) from lib/malloc/xmalloc.c necessary?
e.g.
if (string)
free(string);
Why is this needed? AFAIK the C standard specifies free(NULL) is
completely legal.
Also:
temp = pointer ? realloc
On 01/09/2014 11:06 PM, Pádraig Brady wrote:
On 01/09/2014 07:19 PM, Chet Ramey wrote:
On 1/9/14 12:42 PM, Ondrej Oprala wrote:
Hi, I investigated this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=987975
and found out that some of bash's builtins (source at the very least) d
Hi, I investigated this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=987975
and found out that some of bash's builtins (source at the very least) do
not canonicalize
pathnames given as arguments (builtin "open" is instead fed with the
path - failing in the BZ case).
The builtin "cd" s
Hi, this patch fixes a minor issue of bash not building if compiled with
-Werror=format-security
Thanks,
Ondrej
diff -up bash-4.2/print_cmd.c-orig bash-4.2/print_cmd.c
--- bash-4.2/print_cmd.c-orig 2013-12-04 13:04:35.0 +0100
+++ bash-4.2/print_cmd.c 2013-12-04 13:05:35.0 +0100
@@
dvice on the patch's approach and/or necessary improvements.
Thanks,
Ondrej
>From 3ac7b13686ad4ea477f12bfba759f14e2d05062a Mon Sep 17 00:00:00 2001
From: Ondrej Oprala
Date: Thu, 1 Nov 2012 14:39:27 +0100
Subject: [PATCH] Bash-4.2 patch 40
---
subst.c | 8 +++-
1 file changed, 7 insert
Hi,
unless this bug is already fixed in some way
https://groups.google.com/forum/?fromgroups=#!topic/gnu.bash.bug/xpZl_-eiFCY
...I've created a tiny patch that should fix it.
Cheers,
Ondrej.
diff -up bash-upstream/general.h.patch bash-upstream/general.h
--- bash-upstream/general.h.patch 20
20 matches
Mail list logo