Re: conflict between gcc and bash malloc lib with static link
On 4/7/15 11:36 AM, thibaut.charpent...@tjlc.fr wrote: > Machine Type: i686-pc-linux-gnu > > Bash Version: 4.3.30 > Release Status: release > > Description: > at link step there is a conflict between gcc library in > lib/gcc/i686-linux-gnu/libc.a > and bash library > lib/malloc/libmalloc.a > for malloc and free functions > > Repeat-By: > generation with --enable-static-link Building a static bash on Linux is problematic for several reasons besides the mysterious malloc conflict: shell.o: In function `get_current_user_info': /usr/homes/chet/src/bash/src/shell.c:1718: warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking I suspect the problem with malloc is that there are one or more additional symbols in the file (malloc.o) that glibc uses to satisfy some internal reference, which causes the rest of the symbols from malloc.o to be loaded, which causes conflicts with the already-loaded bash malloc library. > Fix: > adding option --without-bash-malloc look a simple fix > but this generate another issue because in file > lib/sh/shmatch.c there is a reference to sh_xfree > The solution is to add > #include "xmalloc.h" > in file > lib/sh/shmatch.c The actual problem is a missing dependency in lib/sh/Makefile: shmatch.o needs to depend on config.h so it gets rebuilt when config.h changes. shmatch.o already includes xmalloc.h via shell.h, which includes general.h, which includes xmalloc.h. Your editing the file caused it to be rebuilt. In general, it's good to do a `make clean' before you re-run configure with different options. 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: Bash should look at INSIDE_EMACS not just EMACS
On 3/30/15 5:47 PM, Paul Eggert wrote: > Bash Version: 4.3 > Patch Level: 33 > Release Status: release > > Description: > Currently 'bash' looks at the EMACS environment variable when > deciding whether it is running under Emacs. As described in > the "Interactive Subshell" chapter of the Emacs manual > > http://www.gnu.org/software/emacs/manual/html_node/emacs/Interactive-Shell.html > this variable is obsolescent and software is supposed to use the > variable INSIDE_EMACS instead. Thanks for the patch. 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: IFS set to backslash
Hi! Thanks for these analysēs! Please steer stuff like this to the mksh list in the future as well (and/or prod me on IRC). TIA! (Sorry for the late reply, I just discovered this in my postponed-msgs eMail folder and finished it to be sendable.) On Wed, 7 Jan 2015, Eduardo A. Bustamante López wrote: > - ksh93 and mksh behave identically, except for #5 and #11 (I think > this is an mksh bug). > # - code [ # input ] bash ksh93 mksh zsh > bbsh bsh dash > # 5 IFS=\\ read f g; printf %s\\n "$f" # <\^J> <>< <>< > <><><> > # 11 IFS=\\ read f; printf %s\\n "$f" # <\^J> <>< <><> > <><><> From POSIX, this is a ksh93 bug, in which mksh behaves correctly: |By default, unless the -r option is specified, shall |act as an escape character. An unescaped shall preserve |the literal value of the following character, with the exception of |a . If a follows the , the read |utility shall interpret this as line continuation. The |and shall be removed before splitting the input into |fields. All other unescaped characters shall be removed |after splitting the input into fields. The thing to do here seems to be, in both cases: • read reads '<' '\\' '\n' '>' • read removes the '\\' '\n' sequence from the input string, as it’s not called with -r • the remaining string '<' '>' is sent to field splitting, keeping it as-is Could someone™ please inform dgk of this (if he doesn’t read this newsgroup)? > From POSIX, I think the ksh's are wrong in #9 and #10. > # - code [ # input ] bash ksh93 mksh zsh > bbsh bsh dash > # 9 IFS=\\ read f; printf %s\\n "$f" # <\> <><\><\> <> > <><><> > # 10 IFS=\\ read f; printf %s\\n "$f" # <\\><\> <\\> <\\> <\> > <\> <\> <\> Hrm. The '\\' is IFS non-whitespace and thus behaves like 'x'… tglase@tglase:~ $ IFS=\\ read f; printf %s\\n "$f" <\> <\> tglase@tglase:~ $ IFS=x read f; printf %s\\n "$f" tglase@tglase:~ $ IFS=\\ read f; printf %s\\n "$f" <\\> <\\> tglase@tglase:~ $ IFS=x read f; printf %s\\n "$f" … except POSIX additionally says: |All other unescaped characters shall be removed |after splitting the input into fields. So, I agree the correct output for #9 and #10, respectively, is probably '<' '>' and '<' '\\' '>', as in GNU bash and others. > The script I used to generate this is attached. Thank you! bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Re: Sourcing a file ending in \ disables aliases for 1 command
On 4/2/15 5:40 PM, Pedro Gimeno wrote: > Bash Version: 4.2 > Patch Level: 37 > Release Status: release > > Description: > If a file with a command that ends in \ is sourced, the next > command issued in the command line does not interpret aliases but > subsequent ones do. It's a minor issue easy to work around, but since > it's surprising behaviour and some aliases are important, I thought I'd > report it. In the real case where I used it, the command was 'rm' which > was an alias to 'rm -i' to ask for confirmation, and it didn't ask. Thanks for the report. This one was kind of tricky to fix, but it will be fixed in the next release of bash. 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: conflict between gcc and bash malloc lib with static link
On 08 Apr 2015 09:40, Chet Ramey wrote: > I suspect the problem with malloc is that there are one or more additional > symbols in the file (malloc.o) that glibc uses to satisfy some internal > reference, which causes the rest of the symbols from malloc.o to be > loaded, which causes conflicts with the already-loaded bash malloc library. glibc tries pretty hard to avoid symbol conflicts even when static linking. if you're aware of such conflicts, please let us know. there should be no leaking of plain symbols like "foo" or "xmalloc" even w/static libs. -mike signature.asc Description: Digital signature
Usage of __P vs PARAMS in histfile.c
I tried compiling bash with musl-gcc and failed due to the __P macros in histfile.c While digging around it appears that __P is defined in stdc.h, but histfile.c indirectly includes rlstdc.h istead. rlstdc.h defines an identical macro with the name PARAMS instead of __P In my extraordinarily limited testing the switch from __P to PARAMS seems to work. That being said I'm not sure why the usage of __P worked with gcc but not musl-gcc yet, maybe someone more familiar with the code could pitch in and let me know if I've done something wrong. I've attached the patch against the devel branch HEAD. -emg From 4d533ebe10316dbb511088ecc92a4978ad3f0ad5 Mon Sep 17 00:00:00 2001 From: Evan Gates Date: Wed, 8 Apr 2015 08:17:11 -0700 Subject: [PATCH] change __P to PARAMS in histfile.c as far as I can tell histfile.c indirectly includes rlstdc.h not stdc.h both define similar macros the former as PARAMS and the latter as __P --- lib/readline/histfile.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/readline/histfile.c b/lib/readline/histfile.c index 4c23785..a5af01e 100644 --- a/lib/readline/histfile.c +++ b/lib/readline/histfile.c @@ -124,9 +124,9 @@ int history_lines_written_to_file = 0; for more extensive tests. */ #define HIST_TIMESTAMP_START(s)(*(s) == history_comment_char && isdigit ((unsigned char)(s)[1]) ) -static char *history_backupfile __P((const char *)); -static int histfile_backup __P((const char *, const char *)); -static int histfile_restore __P((const char *, const char *)); +static char *history_backupfile PARAMS((const char *)); +static int histfile_backup PARAMS((const char *, const char *)); +static int histfile_restore PARAMS((const char *, const char *)); /* Return the string that should be used in the place of this filename. This only matters when you don't specify the -- 2.3.5
Re: Usage of __P vs PARAMS in histfile.c
On 4/8/15 11:25 AM, Evan Gates wrote: > I tried compiling bash with musl-gcc and failed due to the __P macros > in histfile.c > > While digging around it appears that __P is defined in stdc.h, but > histfile.c indirectly includes rlstdc.h istead. rlstdc.h defines an > identical macro with the name PARAMS instead of __P Yes, you're right. Readline source files need to use PARAMS; bash source files use __P (history -- don't ask). 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: Usage of __P vs PARAMS in histfile.c
On 08 Apr 2015 14:13, Chet Ramey wrote: > On 4/8/15 11:25 AM, Evan Gates wrote: > > I tried compiling bash with musl-gcc and failed due to the __P macros > > in histfile.c > > > > While digging around it appears that __P is defined in stdc.h, but > > histfile.c indirectly includes rlstdc.h istead. rlstdc.h defines an > > identical macro with the name PARAMS instead of __P > > Yes, you're right. Readline source files need to use PARAMS; bash source > files use __P (history -- don't ask). do you still support such old systems that require this pre-ANSI prototypes ? pretty much all other GNU projects have dropped support for them. -mike signature.asc Description: Digital signature
