possible write to an invalid address
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=i686 -mtune=generic -O2 -pipe -ggdb uname output: Linux helios 2.6.31-ARCH #1 SMP PREEMPT Sat Sep 26 02:39:09 CEST 2009 i686 AMD Athlon(tm) XP 2600+ AuthenticAMD GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 33 Release Status: release Description: When bash_dequote_filename() is called with text ending with a backslash and double quote as quote_char, it writes beyond the memory allocated for ret, thus corrupting memory. Repeat-By: This was originally reported as bash crashing when trying to tab-complete: wine "c:\windows\ I can replicate this behaviour on my i686 system. Fix: bash_dequote_filename() checks if *p is '\0' after writing it to r and later writes another '\0' behind that. Move the check before the write: --- bash-4.0.orig/bashline.c2009-10-04 15:06:46.0 +0200 +++ bash-4.0/bashline.c 2009-10-04 15:07:03.0 +0200 @@ -3223,9 +3223,9 @@ bash_dequote_filename (text, quote_char) else if (quoted == '"' && ((sh_syntaxtab[p[1]] & CBSDQUOTE) == 0)) *r++ = *p; - *r++ = *++p; - if (*p == '\0') + if (*++p == '\0') break; + *r++ = *p; continue; } /* Close quote. */
Re: Bash history weirdness
John wrote: > Hi, > > Bash's history command is behaving oddly. > > If I do "history -w" then it writes the current history to > ~/.bash_history as expected. > > But if I do "history -a" then ~/.bash_history doesn't get changed, and > from the modification time it hasn't been touched at all. Look at bashhist.c:maybe_append_history(). If bash doesn't think there have been any new history entries during the current session (history_lines_this_session must be > 0), or if those entries aren't past where we are in the history (history_lines_this_session must be < where_history()), it won't write anything to the history file. If you want to debug it, that's where I'd start. 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: Completion: menu-complete from second TAB hit onwards
Julien Duval wrote: > Thanks for the quick reply Chet. > > I should have insisted on the fact that I don't want the first TAB to insert > a full match. The first TAB should only insert the longest common prefix > between all the possible completions (not a full match). A full match should > only be inserted from the second TAB hit. OK, I understand what you want, and menu completion isn't going to work like that. One of the reasons it exists is to avoid the need to display partial completions. 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: possible write to an invalid address
Henning Garus wrote: > Bash Version: 4.0 > Patch Level: 33 > Release Status: release > > Description: > When bash_dequote_filename() is called with text ending with a > backslash and double quote as quote_char, it writes beyond the memory > allocated for ret, thus corrupting memory. Thanks for the report. This has been fixed for bash-4.1. 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: extglobs in case constructs
Martin von Gagern wrote: >> The reason that [[ conditional commands don't require extglob to be >> enabled while they're executed (and case commands do) lies in how the >> commands are defined to behave. case commands are defined by Posix: >> the pattern is always a Posix shell pattern, and any extension to that >> must be enabled manually. The [[ command, which bash picked up from ksh, >> is defined so that the rhs of `==' is an extended pattern (ksh always >> uses extended patterns, without requiring a special option). For >> compatibility, bash forces the rhs of the [[ command's == and != >> operators to be matched as an extended pattern when executed. > > That's a good explanation, and a valid reason. If you say it's going to > stay that way, I'll accept that and stop suggesting alternatives. It is going to stay that way, with a minor change. I will temporarily enable extglob when parsing the rhs of `==' or `!=' inside a conditional command. The argument that behavior should not depend on current values of shell options but rather on their setting at some arbitrary point in the past is one I don't find particularly compelling. It seems to me that in this particular case, users can either enable extglob to obtain the full benefit of the completion functions or choose to leave it disabled and deal with the consequences of not providing an environment the completion function author expected, with accompanying loss in functionality. Bash-4.1 will also make it easy to default `extglob' to on, settable at configuration time. This should make a different solution to this issue possible, even on a per-vendor basis. 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: Mailcheck and pseudo message in a mailbox
Yarda wrote: > With bash-4.0 the mailcheck behaviour is annoying when there is a pseudo > message in a mailbox, e.g.: It's unfortunate that the system's implementors chose a metadata format that is indistinguishable from a valid mail message. Since bash doesn't read the contents of a mail file at all, it's not a good idea to make it parse mail messages to work around this problem. 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 history weirdness
On 3 Oct 2009 at 20:19, Wanna-Be Sys Admin wrote: > John wrote: >> If I do "history -w" then it writes the current history to >> ~/.bash_history as expected. >> >> But if I do "history -a" then ~/.bash_history doesn't get changed, and >> from the modification time it hasn't been touched at all. > > Where they "new" history lines, or did you run that right after -w? Yes, there was history to write! Actually what happened was that I noticed "history -a" wasn't working, then tried "history -w" and was surprised to find that it *did* work.
