There is a error in xmbsrtowcs.c
Dear Maintainers,
I think here is a bug in
bash-2.05b/lib/glob/xmbsrtowcs.c
36 size_t
37 xmbsrtowcs (dest, src, len, pstate)
38 wchar_t *dest;
39 const char **src;
40 size_t len;
41 mbstate_t *pstate;
42 {
43 mbstate_t *ps;
44 size_t mblength, wclength, n;
45
46 ps = pstate;
47 if (pstate == NULL)
48 {
49 if (!local_state_use)
50 {
51 memset (&local_state, '\0', sizeof(mbstate_t));
52 local_state_use = 1;
53 }
54 ps = &local_state;
55 }
56
57 n = strlen(*src) + 1;
58
59 if (dest == NULL)
60 {
61 wchar_t *wsbuf;
62 char *mbsbuf, *mbsbuf_top;
63 mbstate_t psbuf;
64
65 wsbuf = (wchar_t *) malloc ((n + 1) * sizeof(wchar_t));
66 mbsbuf_top = mbsbuf = (char *) malloc (n + 1);
67 memcpy(mbsbuf, *src, n + 1);
The line 67 will cause bash to crash when
$ls *.o in some directory.
I think it should be
67 memcpy(mbsbuf, *src, n);
After I changed this, it won't crash again.
My machine is FreeBSD6.0 i686.
Sincerely yours
Zhouyi Zhou
Institute of Software
Chinese Academy of Sciences___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Completion of =* directories
Dear Developers of bash, On Mac OS X 10.4 (PowerPC) with 2.05b.0(1)-release-(powerpc-apple- darwin8.0) (built into Tiger?) I get the following "problem": Behaviour+recipe: I have a directory containing subdirs "=e" and "=p" (mnemonic names used allover my file system to keep track of files such that directories are sorted at top when typing ls). When writing e.g. ls = and pressing tab, incorrect completion behaviour is given. Suggested: allow = in directories and filenames in the completion algorithm Best Wishes, Johan Glimming ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash 3.0 problem report - "assertion botched" abort if TERM is invalid on login
Dear Sirs: This problem was seen in version: GNU bash, version 3.00.0(1)-release (powerpc-wrs-linux-gnu) Problem statement: When telnetting to a target that will open a bash shell, if TERM is set to a non-recognized terminal type, bash exits with a cryptic message, closing the telnet session. Example: remote_system> setenv TERM no_term tcsh: using dumb terminal settings. remote_system> telnet bash_system [...] bash_system login: root [...] malloc: unknown:0: assertion botched free: called with unallocated block argument last command: exit Aborting...Connection closed by foreign host. remote_system> _ It is my understanding that in earlier versions of bash, the lack of a valid TERM setting would result in defaulting to dumb terminal settings on login. At the least, it seems that a better error message might be appropriate. As an example of preferable behavior, logging into a machine/account which will invoke tcsh, we get: [...] tcsh: No entry for terminal type "no_term" tcsh: using dumb terminal settings. [...] This is easily re-creatable, and seems to have been seen by others, for example see the following case observed when messing around with TERM in bash 2.04: http://lists.gnu.org/archive/html/bug-bash/2005-05/msg00052.html Please feel free to contact me should you require any further specifics regarding my environment. Nathan Lund Software Engineer Xerox Corporation 1350 Jefferson Road M/S 0801-80A Rochester, NY 14623 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Bug Bash
Hi, I have an server with GNU/Linux 2.4.21-20.0.1 with package bash bash-2.05b-29.0.3 When i worked with bash i have a 100% CPU Could you tell me why ? best regards. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
[PATCH]fix get_history_event in multibytes locale
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu' -DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux gsy2.lepton.home 2.6.13.1-skas3-v8.2 #4 Sat Mar 11 19:11:58 CST 2006 i686 GNU/Linux Machine Type: i386-pc-linux-gnu Bash Version: 2.05b Patch Level: 0 Release Status: release Description: In a multibytes locale like zh_CN, word designators won't work. Repeat-By: export LC_ALL=C !cp:p This will print the content of last cp command. But: export LC_ALL=zh_CN !cp:p This will tell command "cp:p" not found. Fix: The following patch should fix it. diff -pru bash-2.05b/lib/readline/histexpand.c bash-2.05b-lepton/lib/readline/histexpand.c --- bash-2.05b/lib/readline/histexpand.c2002-04-16 23:47:59.0 +0800 +++ bash-2.05b-lepton/lib/readline/histexpand.c 2006-04-24 16:21:52.0 +0800 @@ -217,15 +217,17 @@ get_history_event (string, caller_index, i += v - 1; continue; } - } -else + else #endif /* HANDLE_MULTIBYTE */ - if ((!substring_okay && (whitespace (c) || c == ':' || + if ((!substring_okay && (whitespace (c) || c == ':' || (history_search_delimiter_chars && member (c, history_search_delimiter_chars)) || string[i] == delimiting_quote)) || string[i] == '\n' || (substring_okay && string[i] == '?')) - break; + break; +#if defined (HANDLE_MULTIBYTE) + } +#endif which = i - local_index; temp = (char *)xmalloc (1 + which); ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Bash prompt very slow since bash 3.1
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: i386-redhat-linux-gcc Compilation CFLAGS: -DPROGRAM='bash' - DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386- redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe - Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp- buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind- tables uname output: Linux wyatt.hadess.net 2.6.15-1.1928_FC5 #1 Thu Feb 9 23:27:55 EST 2006 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: Assigning a complicated bash prompt made typing text *much* slower Repeat-By: 1. Install the following .bashrc as the user's .bashrc --8<-- C1="\[\033[1;36m\]" C2="\[\033[0;39m\]" C3="\[\033[1;30m\]" C4="\[\033[0m\]" case $TERM in xterm*|rxvt*) PS1="$C4\[\033];[EMAIL PROTECTED]($C4\w$C3)$C4$C1-> $C4" PS2="$C3-$C4 " ;; esac unset C1 C2 C3 C4 --8<-- 2. Run a terminal emulator 3. Middle-click to paste a long text (the URL to this bug for example) The following comment shows that this is to work-around with some broken types of terminal: /* If this is the first line and there are invisible characters in the prompt string, and the prompt string has not changed, and the current cursor position is before the last invisible character in the prompt, and the index of the character to move to is past the end of the prompt string, then redraw the entire prompt string. We can only do this reliably if the terminal supports a `cr' capability. This is not an efficiency hack -- there is a problem with redrawing portions of the prompt string if they contain terminal escape sequences (like drawing the `unbold' sequence without a corresponding `bold') that manifests itself on certain terminals. */ -- Bastien Nocera <[EMAIL PROTECTED]> I liked the glamour of Hollywood when I first came here, and I guess I still do. -- Jack Nicholson ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Completion of =* directories
> Behaviour+recipe: I have a directory containing subdirs "=e" and > "=p" (mnemonic names used allover my > file system to keep track of files such that directories are sorted > at top when typing ls). When > writing e.g. ls = and pressing tab, incorrect completion behaviour is > given. The `=' is special to the completion code. Either quote it using a backslash or remove it from $COMP_WORDBREAKS. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash prompt very slow since bash 3.1
> Bash Version: 3.1 > Patch Level: 17 > Release Status: release > > Description: > Assigning a complicated bash prompt made typing text *much* > slower Yes, there is a problem with redrawing the prompt multiple times per character in bash-3.1. Things will be improved in bash-3.2. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash prompt very slow since bash 3.1
On Mon, 2006-04-24 at 16:02 -0400, Chet Ramey wrote: > > Bash Version: 3.1 > > Patch Level: 17 > > Release Status: release > > > > Description: > > Assigning a complicated bash prompt made typing text *much* > > slower > > Yes, there is a problem with redrawing the prompt multiple times per > character in bash-3.1. Things will be improved in bash-3.2. Great, thanks for the notice. -- Bastien Nocera <[EMAIL PROTECTED]> ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bug Bash
OULBOUB Lhassan Ext OF/UNPS wrote: > I have an server with GNU/Linux 2.4.21-20.0.1 with package bash > bash-2.05b-29.0.3 > When i worked with bash i have a 100% CPU > Could you tell me why ? You presented very little information to work with. It will not be possible to suggest much. Try 'top' to see what are the top cpu processes. You may have a process in an infinite loop. Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
