Bash 2.05b also reproduces this problem. On Tue, Mar 30, 2010 at 2:36 PM, Clark J. Wang <dearv...@gmail.com> wrote:
> Good news: > > I met this problem again a few minutes ago. Then I looked back to find out > what I was doing. After some investigation I could stably reproduce this > problem by following steps (tested with bash 3.1.17, 3.2.39 and 4.1.0): > > bash$ alias xx='echo 142857' ### Make sure there isn't an external cmd > named `xx' > bash$ export EDITOR=vi > bash$ set -o vi > bash$ ### Press ESC to get out of vi's INSERT mode > bash$ ### Press v to invoke vi to input a cmd like `ls', save and exit, > the `ls' cmd runs. > bash$ xx > -bash: xx: command not found > bash$ xx > 142857 > bash$ > > > On Fri, Jan 29, 2010 at 9:29 AM, Clark J. Wang <dearv...@gmail.com> wrote: > >> On Thu, Jan 28, 2010 at 4:55 PM, Dan Zwell <dzw...@zwell.net> wrote: >> >>> 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-unknown-linux-gnu' >>> -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' >>> -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=x86-64 >>> -mtune=generic -O2 -pipe >>> uname output: Linux mordor 2.6.32-ARCH #1 SMP PREEMPT Mon Jan 18 23:30:46 >>> CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz GenuineIntel >>> GNU/Linux >>> Machine Type: x86_64-unknown-linux-gnu >>> >>> Bash Version: 4.1 >>> Patch Level: 2 >>> Release Status: release >>> >>> Description: >>> When I attempt to run an alias, Bash occasionally says the command >>> is not found. Re-running the command generally succeeds. This also occurs >>> with aliases that are named after existing programs. For example, running >>> "ls", which is aliased to "ls --color", occasionally results in "ls" being >>> run without the "--color" argument (the alias is bypassed). >>> >>> Repeat-By: >>> This problem seems to occur once every few hundred aliased >>> commands I run. It seems more frequent immediately after sourcing a .bashrc >>> file. I cannot reproduce it with a loop that repeatedly runs an aliased >>> command. >>> >>> Is this a known issue? I may be able to help debug this (perhaps by >>> modifying my build to log state when a command is not found). >>> >>> I have the same problem. It's not 4.1 specific. I don't know how to >> reproduce it either but I can see it from time to time. >> >>> Thanks >>> -Dan >>> >>> >>> >> >
