Re: history -a misbehaves with $HISTSIZE
On 2/10/19 4:59 PM, Айрат Васбикарамов wrote: > Machine Type: x86_64-unknown-linux-gnu > Bash Version: 4.4 > Patch Level: 23 > Release Status: release > Description: > $ history -c > $ HISTSIZE=2 > $ HISTFILE=$(mktemp) > $ history -a > $ cat $HISTFILE > $ > File is still empty! > bashhist.c:maybe_append_history(): > if (history_lines_this_session > 0 && (history_lines_this_session <= > where_history ())) > It seems like history_lines_this_session don't affected by HISTSIZE and it's > value 3. But where_history() returns 2. OK, let's look at what happens. The purpose of the -a option is to append new history entries, those not read from the history file and entered in this shell session, to the history file. The goal is to avoid duplicates. The history_lines_this_session is self-explanatory. How many history entries have we seen since this shell session initialized the history list? Since it represents the number of entries in the history list that are new with this shell session, it gets reset to 0 when you clear out the history list with `-c'. Now, how do you determine how many entries in the history list were read from the history file? Well, you make the assumption that if the current offset in the history list is greater than the number of entries entered in the current shell session, you must have some entries there that were read from the history file, and you can go ahead and append the last history_lines_this_session entries to the history file. You can obviously fool this by modifying HISTSIZE and violating the assumption that there is a relationship between the size of the history list and the original number of lines read from the history file. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
bash 5.0 ships with very old autoconf macros
The bash 5.0 release still ships with very old autoconf macros to detect gettext. In aclocal.m4, the copy of gettext.m4 and the supporting lib-link.m4 are from gettext-0.12 dating from 2003. In particular, the included version of AC_LIB_LINKFLAGS_BODY cannot detect shared libraries on OpenBSD. (It checks for *.so; OpenBSD only has fully numbered libraries: *.so.0.0, etc.) These macros should be updated to newer versions from a recent release of gettext. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: AddressSanitizer: heap-use-after-free on (...) in rl_do_undo ../../../bash-devel/lib/readline/undo.c:188
On 2/6/19 12:14 PM, Eduardo A. Bustamante López wrote: > I found another issue in rl_do_undo, but I haven't been successful in > figuring out how it happens. The command string calls execute-last-kbd-macro as part of a macro definition. The internal abort turns off the defining-macro state without completely cleaning up the in-progress macro definition, which leads to an attempt to execute the ill-formed macro recursively. This leads to memory corruption. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
5.0: CPPFLAGS doesn't propagate to loadables
There is a small omission in bash 5.0's build infrastructure:
The CPPFLAGS variable doesn't propagate to the actual compiler flags
used to build the loadables. In practice, this means that the seq
loadable will fail to build on operating systems that have libintl
outside the default paths (e.g. OpenBSD with GNU gettext in /usr/local):
cc -fPIC -DHAVE_CONFIG_H -DSHELL -DDEV_FD_STAT_BROKEN -O2 -pipe
-Wno-parentheses -Wno-format-security -I. -I.. -I../.. -I../../lib
-I../../builtins -I. -I../../include -I/usr/obj/bash-5.0.2/bash-5.0
-I/usr/obj/bash-5.0.2/bash-5.0/lib -I/usr/obj/bash-5.0.2/bash-5.0/builtins -c
-o seq.o seq.c
In file included from seq.c:32:
In file included from ../../bashintl.h:30:
../../include/gettext.h:27:11: fatal error: 'libintl.h' file not found
# include
^~~
1 error generated.
Trivial fix:
Index: examples/loadables/Makefile.in
--- examples/loadables/Makefile.in.orig
+++ examples/loadables/Makefile.in
@@ -76,7 +76,7 @@ INTL_BUILDDIR = ${LIBBUILD}/intl
INTL_INC = @INTL_INC@
LIBINTL_H = @LIBINTL_H@
-CCFLAGS = $(DEFS) $(LOCAL_DEFS) $(LOCAL_CFLAGS) $(CFLAGS)
+CCFLAGS = $(DEFS) $(LOCAL_DEFS) $(LOCAL_CFLAGS) $(CPPFLAGS) $(CFLAGS)
#
# These values are generated for configure by ${topdir}/support/shobj-conf.
--
Christian "naddy" Weisgerber na...@mips.inka.de
What is the purpose of ASSIGNMENT_WORD?
Hi,
I know that ASSIGNMENT_WORD in parse.y is for assignments like x=10.
But in the grammar rules. I don't see any difference between them in
terms of actions to take. Where is the code that deals with them
differently?
Also, why parse x=10 as a single token. Why not parse it as three
tokens "x" "=" "10"? Is it because one wants to control the complexity
of the grammar? Thanks.
https://github.com/mfragkoulis/bash/blob/master/parse.y#L710
simple_command_element: WORD
{ $$.word = $1; $$.redirect = 0; }
| ASSIGNMENT_WORD
{ $$.word = $1; $$.redirect = 0; }
https://github.com/mfragkoulis/bash/blob/master/parse.y#L3098
if (token_to_read == WORD || token_to_read == ASSIGNMENT_WORD)
{
yylval.word = word_desc_to_read;
word_desc_to_read = (WORD_DESC *)NULL;
}
https://github.com/mfragkoulis/bash/blob/master/parse.y#L5748
case WORD:
case ASSIGNMENT_WORD:
if (yylval.word)
t = savestring (yylval.word->word);
break;
https://github.com/mfragkoulis/bash/blob/master/parse.y#L6030
if (tok != WORD && tok != ASSIGNMENT_WORD)
--
Regards,
Peng
Bash 4 crash: "f(){ declare -a x;declare -A x;};f"
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include
-I./lib -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux skami 4.19.12-1-CHAKRA #1 SMP PREEMPT Fri Dec 28
13:42:52 CET 2018 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.4
Patch Level: 18
Release Status: release
Description:
Bash versions 4.0 thru 4.4.18 crash when declaring a variable as an
indexed array and then as an associative array while inside of a
function.
Note that the opposite declaration order doesn't cause a crash, and
neither does the same thing outside of a function. Also, other
things can happen inside the function before the crash; it
ultimately crashes on function return.
Repeat-By:
Run this code in a Bash 4.x shell that you don't don't mind
crashing. "f() { declare -a x; declare -A x; }; f"
Fix:
Get everyone to upgrade to Bash 5.0, which is unaffected.
