[Bash-completion-devel] Work-needing packages report for Oct 24, 2008

Sun Jan 31 08:01:51 UTC 2010

On Sunday 31 January 2010 00:07:52, Michelle Konzack wrote:
> Hello Maintainers,

Hi Michelle,

> are you alive or is the mailing list only BOT-DRIVEN?

We're alive :)

> Here th 8th or t10th time:
> 
> 
> 
> according to:
> 
> Am 2008-10-24 00:27:15, schrieb wnpp at debian.org:
> >    bash-completion (#472468), requested 213 days ago
> >      Description: programmable completion for the bash shell
> >      Installations reported by Popcon: 17723
> 
> ------------------------ END OF REPLIED MESSAGE ------------------------

That bug got closed a while ago, I wonder why it appeared on the report.

> you have asked for help and I have now written several times but  gotten
> no answer.

We got none, AFAICT :/

> Also I have tried to  subscribe  to  <bash-completion-devel> but it seems,
> it does not work for me.
> 
> Do I need special permissions to subscribe?

Not really, something wrong must be happening between Alioth and you. But I 
can't tell what.

> Please CC me in any replys...

Done.

> OK, however, I like to know, which help you need,  since  I  have  found
> tonns of reassignments from bash->bash-completion  where  many  of  them
> sounds a little bit weird, since in the describtion it is written.
> 
> ----[ command 'pkg_desc bash-completion' ]------------------------------
> Description: programmable completion for the bash shell
>  bash completion extends bashs standard completion behavior to achieve
>  complex command lines with just a few keystrokes.  This project was
>  conceived to produce programmable completion routines for the most
>  common Linux/UNIX commands, reducing the amount of typing sysadmins
>  and programmers need to do on a daily basis.
> ------------------------------------------------------------------------
> 
> I mean exactly THE SENTENCE "most common Linux/UNIX commands" since  the
> following bugreports should be reassigned to the  appropriated  packages
> since they are NOT "most common commands".

I believe we could drop that sentence from the description. Also, I can't 
really say what our Policy currently is. I remember once we (or maybe only I?) 
planned to only keep the infrastructure, and move completions in the 
appropriate packages; that would've meant losing "access" to the completions 
and probably leaving them rotting around the net, I suppose.

> Note 1: For any of my own packages  which  has  executables  I  have  an
>         appropriated bash_completion file

What do you mean by "appropriate"? I'm in the process of writing an API 
document for bash-completion :)

>         and instead forcing  users  to load a several 100 kByte large singel 
>         bash_completion  file,  I
>         would go for the /etc/bash_completion.d/ directory OR if it  can
>         produce a to high IO a "postinst" script which  then  merge  the
>         files from there into a singel one.  If requested, I am  willing
>         to develop the script  and  of  course,  a  "dh_bash-completion"
>         command...

We're already splitting things out of bash_completion, and... seems like you 
missed the debhelper:

bash-completion (20080617) unstable; urgency=low

  [ David Paleino ]
  * New upstream release
    [..]
    - added extra/dh_bash-completion to ease future rewrite of bc.
    [..]
 -- Luk Claes <luk at debian.org>  Sat, 21 Jun 2008 21:59:43 +0200

> Note 2: I have had already written a small (X)dialog tool which let user
>         choose between a full ~/.bash_completion file  or  a  small  one
>         with user selectable items...

We plan to handle that in 2.0; probably using symlinks?
Also, we plan to change directory structure.

> Bug#415276: bash: [COMPLETION] completing - or -- with _command prints
>  error -> I can not reproduce this on my system

This bug is closed.. why are you posting things about closed bugs? :)

Closed bugs you posted, other than the above: 416655, 413374, 463969, 459130, 
340452, 314363, 297065, 452083, 444254, 441017, 259987, 386817, 301241, 
445332, 131101, 315515, 409423, 456887, 452435, 443394, 392495, 269173, 
303536, 433542, 361535, 365658, 309612, 428641, 444294, 435117, 257317, 
272660, 278295, 315515, 396644, 438471, 431220, 372156, 404976, 360628, 
391920, 432289, 379144, 400678, 347316, 400380, 367957, 463756, 429766, 
376433, 318571, 426102, 428085, 413170, 339111, 356386, 414821, 466089

This means, you reported 59 already closed bugs! :/

> Bug#299229: /etc/bash_completion: 'ci -u prefix<TAB>' hit on RCS/prefix
>  shadows ./prefix -> Package:
> 
> Bug#412944: set command lists contents of /etc/bash_completion
> -> wontfix:  It is the BaSH which output it and I do not like the idea,
>              that "set" refuse to output VAR's which begin with a "_"
> 
> Bug#111467: bash: Tab completion fails when dealing with a file with a : in
>  the name. Bug#100743: bash: inconsistent handling of filename completion
>  wrt colons Bug#199042: tab completion bug for filenames containing colon
> -> for which command?  It works here perfectly (Maildir)
> 
> Bug#330833: bash: [COMPLETION] Please complete ssh host with {} globbing
> -> Package: ssh
> 
> Bug#366899: bash completion acts weird on dpkg-source
> -> Package:
> 
> Bug#120910: command completion on *foo
> -> could be solved with a liitle bit heavy (resources consuming) coding

Not likely going to be solved :)

> Bug#121631: enable expansion inside `which *`
> -> can not reproduce this bug since it work here...
>        cd /etc
>        TEST=`which b*<tab>`
>    is working perfectly and this bug should be closed

$ TEST=`which b<TAB>`
$ TEST=`which bin/`

Which is obviously wrong. (bin/ is a directory I have in $CWD, not a command 
in $PATH)

> Bug#320390: bash: Does not tab complete a file created after tab is pressed
>  once -> can not reproduce this bug

I remember being able to reproduce it, should check against newer versions 
though.

> Bug#309463: bash: completion for /usr/bin/env
> -> Works in Etch and Lenny...
>        [michelle.konzack at samba3:/etc] env --
>        --help                --ignore-environment  --unset=             
>  --version

The user is asking for treating "env" as a meta-command, like sudo.

> Bug#446355: bash: [COMPLETION] sudo -e should list filenames instead of
>  commands -> easy to fix

Are you sure? ;)

> Bug#467231: bash_completion is big and loads slowly; load-by-need proposed
> -> Ack!

We're already planning on merging with bash-completion-lib, probably 
targetting 3.0.

Wontfixes:

> Bug#427758: [COMPLETION] filenames starting with =
> -> wontfix
> 
> Bug#393338: tab completion should show dirs in blue and executables in
>  green -> wontfix
> 
> Bug#340747: bash completion does not show 'make menuconfig' in kernel tree
> -> can not reproduce this bug...
> 
> Bug#313514: bash-completion fails with e.g., ls and newlines in file names
> -> wontfix
> 
> Bug#267060: bash: completion error commands/directories conflict
> -> can not reproduce this
> 
> Bug#323613: bash: [COMPLETION] fail to complete commands when prefixed with
>  variable assignment -> wontfix since the variable can be anything and will
>  only be expanded by command execution
> 
> Bug#377935: bash: [COMPLETION] completion of ':' mangles filename
> -> Can not reproduce this
> 
> Bug#128997: bash-completion: debconf question for the addition to
>  /etc/bash.bashrc? Bug#116082: bash: Some debconf questions for defaults in
>  .bash* files? Bug#242298: Request change standard .bashrc to help newbies
> -> Ah and bothereing 90% of all Server-Admins and long-Term Debian users...
>    bash-comletion is user stuff and not system stuff

This is wontfix too, missed it? :)

Not bash-completion's bugs:

> Bug#464210: bash dies when tab completing tilde paths via LDAP query
> -> Package: ???
>
> Bug#430501: /etc/skel/.bashrc: bash_completion example in default .bashrc
>  should check for previous inclusion via $BASH_COMPLETION -> could only be
>  fixed if a UNIQUE dummy variable from bash_completion is set
>
> Bug#425440: bash: Option to versionsort completions
> ->
> 
> Bug#466610: bash: crash on tab completion of user name
> -> can not reproduce this with libnss-pgsql and maybe it is LDAP related

Regarding uncommented bugs of the above, I can't say anything right now. I 
should take a moment and triage them, but ENOTIME currently (exams at 
university..) :)

Have a nice day,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|----
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20100131/5ce47698/attachment.pgp>