Your message dated Tue, 12 Feb 2013 10:54:20 +0000
with message-id 
<CANBHLUisWc-Ng+Mkq7SC=5xyVmijAKHeES-V=84_qftqy+d...@mail.gmail.com>
and subject line Re: bash: autocompletion now prepends environment variables 
with \$, fails on 2nd autocomplete
has caused the Debian Bug report #650626,
regarding bash: autocompletion now prepends environment variables with \$, 
fails on 2nd autocomplete
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
650626: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650626
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: bash
Version: 4.2-1
Severity: normal

The latest bash changes how autocomplete works. When I use TAB or
double-ESC to expand a environment variable that resolves to a directory
name, bash will show the contents of the directory, but then the command
line is repeased with "\$" prepended to the environment variable. A
second attempt to autocomplete then fails.

This means that one of the main uses of autocomplete, namely to make
searches through a directory tree, no longer works.

Example: attempt to view contents of directory and then cd into proper
subdirectory

FOO="bar"

where "/bar" is the name of a directory

# cd $FOO/[TAB]

 ==> expected (old) results: directory entries displayed, command line
re-displayed as "cd bar/" with cursor at end of line
     Hitting TAB again will cause he dir entries to be displayed again
     If we start to type the name of dir entry and hit TAB again, the
new candidate filenames displayed

==> actual (new) results: diretory entries displayed, command line
re-displayed as "cd \$FOO/"
    Now if we hit TAB again, the line refuses to complete because of the
variable name is escaped
    This of course will hold true if we attempt to autocomplet to a
subdirectory

I tried installing the "bash-completion" package and sourcing it, but it
does not help.

I see this thread,
http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00282.html, as
well as this old bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278295


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages bash depends on:
ii  base-files   6.5
ii  dash         0.5.7-2
ii  debianutils  4.0.4
ii  libc6        2.13-21
ii  libtinfo5    5.9-4

Versions of packages bash recommends:
ii  bash-completion  1:1.3-1

Versions of packages bash suggests:
pn  bash-doc  <none>

-- no debconf information

-- 
Moshe Yudkowsky * [email protected] * www.pobox.com/~moshe
 "You may fire when ready, Gridley." -- Commodore George Dewey



--- End Message ---
--- Begin Message ---
Version: 4.2-3

This bug was fixed in 4.2-3

    - Bash-4.2 tries to leave completed directory names as the user typed them,
      without expanding them to a full pathname. One effect of this is that
      shell variables used in pathnames being completed (e.g., $HOME) are left
      unchanged, but the `$' is quoted by readline because it is a special
      character to the shell. This patch introduces two things:
      - A new shell option, `direxpand', which, if set, attempts to emulate the
        bash-4.1 behavior of expanding words to full pathnames during
        completion;
      - A set of heuristics that reduce the number of times special characters
        such as `$' are quoted when the directory name is not expanded.

Regards,

Dmitrijs.

--- End Message ---

Reply via email to