Vertical tab on commandline in UTF-8 mode crashes bash.
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: freebsd5.5 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='freebsd5.5' -DCONF_MACHTYPE='i386-unknown-freebsd5.5' -DCONF_VENDOR='unknown' -DLOCALEDIR='/home/svdb/bashtemp/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -I./lib/intl -I/home/svdb/src/bash-3.1/lib/intl -g -O0 uname output: FreeBSD frog.stack.nl 5.5-RELEASE-p1 FreeBSD 5.5-RELEASE-p1 #6: Mon Jun 12 18:16:16 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FROG i386 Machine Type: i386-unknown-freebsd5.5 Bash Version: 3.1 Patch Level: 0 Release Status: release Description: When the LANG environment variable is set to an UTF-8 encoding, giving a command containing a vertical tab character will cause bash to race and eventually crash. This does not happen on all systems; I suspect this has something to do with the locale definitions. It worked on a FreeBSD 5.5 box. On closer investigation it appears the following is happening: parse.y line 2559: while ((character = shell_getc (1)) != EOF && whitespace (character)) will stop at the vertical tab; whitespace() returns false for it. parse.y line 3594: if MBTEST(shellbreak (character)) will see the vertical tab as a word break character; shellbreak() returns true for it. The result is that an empty string is taken as a word and no progress is made. And as for each found word memory is allocated, (parse.y line 3672 and onwards: the_word = (WORD_DESC *)xmalloc (sizeof (WORD_DESC)); the_word->word = (char *)xmalloc (1 + token_index); strcpy (the_word->word, token); ) eventually the process will run out of memory, and it will crash. Repeat-By: On a FreeBSD system: env -i `which bash` --norc -c 'export LANG=en_GB.UTF-8; eval `printf \\\v`' ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Bash expansion nuance or bug?
I ran into an oddity in alias expansion. I don't know if it is a bug, or some feature I'm unfamiliar with: Two aliases: alias ls='ls -CFG --show-control-chars --color=tty ' alias dir='ls' If I type "ls dir" (created a test dir called dir), I get: "ls dir" I get: ls: ls: No such file or directory. This was "unexpected". Tracing showed: /tmp> ls foo + ls -CFG --show-control-chars --color=tty foo ls: foo: No such file or directory ---the above is "normal"---but below: /tmp> ls dir + ls -CFG --show-control-chars --color=tty ls -CFG --show-control-chars --color=tty ls: ls: No such file or directory Where the filename should have been I see dir treated as another alias to be expanded. Huh? I traced the cause to the ls alias -- the "space" at the end of the alias is causing the behavior: with space, it expands "dir" as another alias. Without the space at the end, it works as I would have normally expected. Is this a bug, or some feature I'm unfamiliar with? Thanks, -linda ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash expansion nuance or bug?
Linda Walsh <[EMAIL PROTECTED]> wrote: > Two aliases: >alias ls='ls -CFG --show-control-chars --color=tty ' >alias dir='ls' > > If I type "ls dir" (created a test dir called dir), I > get: >"ls dir" > I get: >ls: ls: No such file or directory. man bash, under ALIASES: # If the last character of the alias value is a blank, then the next # command word following the alias is also checked for alias # expansion. paul ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash expansion nuance or bug?
> I ran into an oddity in alias expansion. I don't know if it > is a bug, or some feature I'm unfamiliar with: >From 'man bash', under the section ALIASES: "If the last character of the alias value is a blank, then the next command word following the alias is also checked for alias expansion." This is intentional, so that you can do something like: alias nice='nice -n 5 ' and then 'nice ls' will still use the aliases you normally have for ls. -- Eric Blake ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Bash expansion nuance or bug?
Ah! Don't remember reading those lines under aliasesuseful, I agree, though, even with documentation, it seems a bit obscure. Something to file under "Bash Arcana". :-) thanks! -linda ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
