From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830 Description of problem: In bash 1, if I have a subdirectory "veryLongDir" containing the executable "longerExecutable", I can run it by typing "./ver<tab>", at which point "./veryLongDir/" appears, then I can type "lon<tab>" and the full "./veryLongDir/veryLongExecutable " appears, ready for me to type arguments. Great! In Bash 2.05b, it inserts a space instead of the "/" after the "veryLongDir/", so I type "./ver<tab>", get "./veryLongDir ", and then I must go and manually backspace, press "/", then type again to get the next level. When I have a binary several subdirectories deep, this is incredibly annoying. Since having a directory name as the first part of a shell command is useless, it seems this is strictly wrong behavior, it should always insert the "/" instead of the space. Version-Release number of selected component (if applicable): 2.05b How reproducible: Always Steps to Reproduce: 1. mkdir veryLongDir 2. echo ls >veryLongDir/longerBinary 3. chmod +x veryLongDir/longerExecutable 4. ./ver<tab> Actual Results: Command prompt shows useless "./veryLongDir " Expected Results: It should show "./veryLongDir/" Additional info: Note that if you tab-complete as an argument, it does the right thing; "cat ./ver<tab>" will turn command prompt into "cat ./veryLongDir/". So it is only wrong when you are typing the executable name.
*** This bug has been marked as a duplicate of 72512 ***