Re: bash decode prompt string broken for 'W'
> 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-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/shar > uname output: Linux gohan 2.6.37-2-amd64 #1 SMP Sun Feb 27 10:12:22 > UTC 2011 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 4.1 > Patch Level: 5 > Release Status: release > > Description: > The "\W" escape in the prompt is expanded incorrectly for some > directories. The problem is caused by the use of strcpy with > overlapping strings; but strcpy has undefined behaviour when the > strings overlap. Upgrade. This is fixed by bash-4.1 patch 10. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Potential bug in library search for libiconv in static build
On 4/3/11 9:01 AM, gmail wrote: > Hello, > > This is my first contact and mail with bash mailing list, to summarize i'm > a coder maintening a personnal home server using several GNU tools since > the late 90's. > > > I configure BASH-4.2.0 in a chroot jail (gcc 4.5.2/libc 2.13/binutils > 2.21/make 3.82) with an athlon architecture on ext3 FS with > --enable-static-link --with-libiconv-prefix=/ and, as root, and notice the > configure script can't find the jail's static libiconv : > [...] > So, as you could see, the configure script try to build a static elf by > linking object output with a shared libiconv.so library. > Guessing that this behavior was not the script real goal, i then adapt the > configure script this way : It's usually better to modify configure.in/aclocal.m4 and then rebuild configure, but I see what you're trying to do. I picked up these macros from the libiconv distribution, so I'll have to take a look at what that distribution needs to inhibit searching for static libraries. It's probably something as simple as setting a different shell variable in configure. > For information, the configure script needs other adaptations to produce a > functionnal STATIC bash elf with glibc 2.13 due to specific dlopen issue. > I have currently inhibit getaddrinfo, gethostbyname, getpwent, getpwam, > getpwuid, getservbyname, getservent use in configure script when STATIC > build is required and alter some sources to behave differently if in static > build. > This way i have actually a functionnal static bash 4.2 elf which passes all > the tests except the multybite printf2.sub test (return 195 and not 192, > i'm currently investigating). > I can provide the related patchs, if you think it's worth it. Sure, I'd be interested in taking a look at your patches. Note that this is mostly a linux-specific issue. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Potential bug in library search for libiconv in static build
Hello, I have take a deep breath and dive in the autotools documentation. Here is the resulting patch that i think (hope ?) should be ok with any hosts/shells/archs : --- bash-4.2_static/aclocal.m4.orig 2011-04-03 14:02:35.0 +0200 +++ bash-4.2_static/aclocal.m4 2011-04-05 00:24:55.0 +0200 @@ -3098,7 +3098,9 @@ found_so= found_a= if test $use_additional = yes; then -if test -n "$shlibext" && test -f "$additional_libdir/lib$name.$shlibext"; then + dnl A shared AND a static version of the same library could be present, + dnl therefore if build is static only the static version must be looked for. +if test -n "$shlibext" && test -f "$additional_libdir/lib$name.$shlibext" && test "$opt_static_link" = no; then found_dir="$additional_libdir" found_so="$additional_libdir/lib$name.$shlibext" if test -f "$additional_libdir/lib$name.la"; then @@ -3120,7 +3122,9 @@ case "$x" in -L*) dir=`echo "X$x" | sed -e 's/^X-L//'` - if test -n "$shlibext" && test -f "$dir/lib$name.$shlibext"; then + dnl A shared AND a static version of the same library could be present, + dnl therefore if build is static only the static version must be looked for. + if test -n "$shlibext" && test -f "$dir/lib$name.$shlibext" && test "$opt_static_link" = no; then found_dir="$dir" found_so="$dir/lib$name.$shlibext" if test -f "$dir/lib$name.la"; then The m4 compile is ok and work correctly for both static and shared build of bash-4.2 : [root@pompomgalli] cd bash-4.2_static_build [root@pompomgalli] make configure cd ../bash-4.2_static && autoconf configure.in:923: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body ../../../autoconf-2.68/lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from... ../../../autoconf-2.68/lib/autoconf/general.m4:2730: _AC_RUN_IFELSE is expanded from... ../../../autoconf-2.68/lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../../autoconf-2.68/lib/autoconf/general.m4:2749: AC_RUN_IFELSE is expanded from... ../../../autoconf-2.68/lib/m4sugar/m4sh.m4:606: AS_IF is expanded from... ../../../autoconf-2.68/lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from... aclocal.m4:4127: BASH_STRUCT_WEXITSTATUS_OFFSET is expanded from... configure.in:923: the top level /bin/sh ./config.status --recheck running CONFIG_SHELL=/bin/sh /bin/sh ../bash-4.2_static/configure --prefix=/ --without-bash-malloc --with-curses --enable-static-link --with-libiconv-prefix=/ CC=gcc CFLAGS=-g -O2 -fomit-frame-pointer -march =athlon CPPFLAGS=-fexceptions --no-create --no-recursion checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu Beginning configuration for bash-4.2-release for i686-pc-linux-gnu checking whether we are using the GNU C Library 2.1 or newer... yes checking whether integer division by zero raises SIGFPE... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unsigned long long... yes checking for inttypes.h... yes checking whether the inttypes.h PRIxNN macros are broken... no checking for ld used by GCC... /bin/ld checking if the linker (/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking for __argz_count... yes checking for __argz_stringify... yes checking for __argz_next... yes checking for __fsetlocking... yes checking for iconv... yes checking how to link with libiconv... //lib/libiconv.a checking for iconv declaration... extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); configure: creating ./config.status CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status config.status: creating Makefile config.status: executing default-1 commands config.status: executing default commands [root@pompomgalli] make gcc -L./builtins -L./lib/readline -L./lib/readline -L./lib/glob -L./lib/tilde -L./lib/sh -static -static -rdynamic -g -O2 -fomit-frame-pointer -march=athlon -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh -lreadline -lhistory -ltinfo -ltilde //lib/libiconv.a ls -
Misspelling of "sequence" in reference manual
Hi,
In section 3.5.1 Brace Expansion of the Bash Reference Manual,
"sequence" is misspelled "seqeunce".
--
Matt Kraai
https://ftbfs.org/kraai
diff -C2 -r bash-4.2~/doc/bashref.texi bash-4.2/doc/bashref.texi
*** bash-4.2~/doc/bashref.texi 2011-04-04 20:30:51.0 -0700
--- bash-4.2/doc/bashref.texi 2011-04-04 20:31:36.0 -0700
***
*** 1555,1559
but the file names generated need not exist.
Patterns to be brace expanded take the form of an optional @var{preamble},
! followed by either a series of comma-separated strings or a seqeunce expression
between a pair of braces,
followed by an optional @var{postscript}.
--- 1555,1559
but the file names generated need not exist.
Patterns to be brace expanded take the form of an optional @var{preamble},
! followed by either a series of comma-separated strings or a sequence expression
between a pair of braces,
followed by an optional @var{postscript}.
