Debian Bug report logs - #498579
Please write a manpage describing /etc/bash_completion.d/ and bash-completion

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Lucio Crusca <lucio@sulweb.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Date: Wed, 10 Sep 2008 12:28:49 +0200

Subject: bash-completion: TAB always outputs -sh: <( compgen -f -X  -- '...' ): No such file or directory
Package: bash-completion
Version: 20080705
Severity: grave
Justification: renders package unusable


Whenever I type a prefix and then hit TAB, I see the folowing on the console:

-sh: <( compgen -d -- 'Mai' ): No such file or directory
-sh: <( compgen -f -X  -- 'Mai' ): No such file or directory

where Mai is the prefix I've keyed in.
The output of ls is:

$ ls
log  Maildir

The bug happens with any command, be it "cd Mai<TAB>", "rm -rf Mai<TAB>", "ls Mai<TAB>" or others.
It happens even when there's no file starting with the prefix.

I think the bug is a grave one because my bash-completion is actually unusable.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages bash-completion depends on:
ii  bash                          3.2-4      The GNU Bourne Again SHell

bash-completion recommends no packages.

bash-completion suggests no packages.

-- no debconf information

Message #14 received at 498474-quiet@bugs.debian.org (full text, mbox, reply):

From: David Paleino <d.paleino@gmail.com>

To: 498474-quiet@bugs.debian.org

Cc: Lucio Crusca <lucio@sulweb.org>, Bash-Completion Developers <bash-completion-devel@lists.alioth.debian.org>

Subject: Re: [Bash-completion-devel] Bug#498474: TAB always outputs -sh: <( compgen -f -X -- '...' ): No such file or directory

Date: Wed, 10 Sep 2008 21:50:40 +0200

[Message part 1 (text/plain, inline)]

tags 498474 unreproducible moreinfo
thanks

Ciao Lucio,

On Wed, 10 Sep 2008 12:28:49 +0200, Lucio Crusca wrote:

> Whenever I type a prefix and then hit TAB, I see the folowing on the console:
> 
> -sh: <( compgen -d -- 'Mai' ): No such file or directory
> -sh: <( compgen -f -X  -- 'Mai' ): No such file or directory

That "-sh" is looking weird to me. 

If you look at the source code, those lines should be in the _filedir() function
(marked with *):

_filedir()
{
    local IFS=$'\t\n' xspec

    _expand || return 0

    local toks=( ) tmp
    while read -r tmp; do
        [[ -n $tmp ]] && toks[${#toks[@]}]=$tmp
*   done < <( compgen -d -- "$(quote_readline "$cur")" )
    
    if [[ "$1" != -d ]]; then
        xspec=${1:+"!*.$1"}
        while read -r tmp; do
            [[ -n $tmp ]] && toks[${#toks[@]}]=$tmp
*       done < <( compgen -f -X "$xspec" -- "$(quote_readline "$cur")" )
    fi

    COMPREPLY=( "${COMPREPLY[@]}" "${toks[@]}" )
}


As you can see, that "-sh" is not appearing anywhere.
Did you hack our code? ;) :P

> where Mai is the prefix I've keyed in.
> The output of ls is:
> 
> $ ls
> log  Maildir
> 
> The bug happens with any command, be it "cd Mai<TAB>", "rm -rf Mai<TAB>", "ls
> Mai<TAB>" or others. It happens even when there's no file starting with the
> prefix.
> 
> I think the bug is a grave one because my bash-completion is actually
> unusable.

I'm sorry but... well... I just can't reproduce it:

$ pwd
/tmp
$ mkdir bug
$ cd bug/
$ pwd
/tmp/bug
$ touch log; mkdir Maildir
$ cd Mai<TAB>
$ cd Maildir/^C
$ rm -rf Mai<TAB>
$ rm -rf Maildir/^C
$ ls Mai<TAB>
$ ls Maildir/^C
$


My suggestion here is to try reinstalling bash-completion:

# apt-get --reinstall install bash-completion

Hope this helps,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

[signature.asc (application/pgp-signature, attachment)]

Message #19 received at 498474@bugs.debian.org (full text, mbox, reply):

From: Neil Williams <codehelp@debian.org>

To: 498474@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Need information on which packages have installed completion scripts

Date: Wed, 10 Sep 2008 20:55:31 +0100

[Message part 1 (text/plain, inline)]

Package: bash-completion
tag 498474 + moreinfo
thanks

1. edit ~/.bashrc and comment out:
. /etc/bash_completion

2. send a reply including the output of:
$ ls /etc/bash_completion.d/

Note that none of these packages would seem affected:
neil@holly:~$ ls -1 /etc/bash_completion.d/
apache2.2-common
dbs-edit-patch
debconf
deborphan
desktop-file-validate
devscripts.chdist
dpatch_edit_patch
dput
emdebian-qa
emdebian-rootfs
emdebian-tools
gammu
git
monotone
ooffice.sh
pbuilder
pon
quilt
reprepro
subversion
svn-buildpackage

So a diff against that would be handy too.

It shouldn't be hard for you to identify which file in that directory is
buggy then re-assign the bug to the package that installs that file.

I don't see that this is RC buggy though - certainly not for
bash-completion.

/me wants a way to make it much harder to report RC bugs
/me also wants a way to stop users thinking that only RC bugs get any
attention.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

[signature.asc (application/pgp-signature, inline)]

Message #28 received at 498474-quiet@bugs.debian.org (full text, mbox, reply):

From: Hanska <aksnah@gmail.com>

To: 498474-quiet@bugs.debian.org

Cc: Neil Williams <codehelp@debian.org>, 498474-submitter@bugs.debian.org

Subject: Re: [Bash-completion-devel] Bug#498474: Need information on which packages have installed completion scripts

Date: Wed, 10 Sep 2008 22:09:32 +0200

[Message part 1 (text/plain, inline)]

severity 498474 important
thanks

Hello Neil,
thanks for acting on this bug :)

(you just arrived a few minutes late :P)

On Wed, 10 Sep 2008 20:55:31 +0100, Neil Williams wrote:

> Package: bash-completion
> tag 498474 + moreinfo
> thanks
> 
> 1. edit ~/.bashrc and comment out:
> . /etc/bash_completion
> 
> 2. send a reply including the output of:
> $ ls /etc/bash_completion.d/
> 
> Note that none of these packages would seem affected:
> neil@holly:~$ ls -1 /etc/bash_completion.d/
> [..]

To the OP: that's a ONE, not an L :)

> [..]
> 
> I don't see that this is RC buggy though - certainly not for
> bash-completion.

And, in fact, in my previous mail I set it to "important"... (oops, no I
didn't, lowering it right now.)

> /me wants a way to make it much harder to report RC bugs

I don't see that as an easy thing to do...

> /me also wants a way to stop users thinking that only RC bugs get any
> attention.

That's true :)... but that probably is just a common "human" misconception...
«the higher the priority (or "urgency"), the faster the response»...

Thanks for your help here,
David

-- 
         Linux Registered User #334216
Get FireFox! >> http://snipurl.com/gofoxygo/ <<
Blog         >>  http://www.hanskalabs.net/  <<
Staff        >> http://www.debianizzati.org/ <<

[signature.asc (application/pgp-signature, attachment)]

Message #36 received at 498474-quiet@bugs.debian.org (full text, mbox, reply):

From: David Paleino <d.paleino@gmail.com>

To: 498474-quiet@bugs.debian.org

Cc: 498474-submitter@bugs.debian.org, Neil Williams <codehelp@debian.org>

Subject: Re: [Bash-completion-devel] Bug#498474: Bug#498474: Need information on which packages have installed completion scripts

Date: Wed, 10 Sep 2008 22:22:21 +0200

[Message part 1 (text/plain, inline)]

On Wed, 10 Sep 2008 22:09:32 +0200, Hanska wrote:

> [..]

Argh!!! WTF?! What happened?!... ok, you just discovered my hidden
identity ;) :D

That's me, however.

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

[signature.asc (application/pgp-signature, attachment)]

Message #44 received at 498474@bugs.debian.org (full text, mbox, reply):

From: Lucio Crusca <lucio@sulweb.org>

To: 498474@bugs.debian.org

Subject: moreinfo

Date: Thu, 11 Sep 2008 02:28:18 +0200

Currently I have no access to the only box where I can reproduce this bug (it 
is a fileserver at a customer's office). However I'll post here all the info 
you ask as soon as I can access the server.

<rant>
About the RC bug argument: I didn't even know that a grave bug is RC while an 
important one isn't. I simply read the instructions that reportbug prints on 
the screen: it says that the bug is grave when the package is completely 
unusable, and that's exactly the situation on said server. Is it not a 
bash-completion bug? Ok, I take your word, but please recognize it's not easy 
for non-developers to identify the right package... a common user who takes 
himself the time to report a bug could even think it's a bash bug (though a 
minor one in that case). I think you developers/maintainers should be 
thankful when someone reports a bug, instead of complaining about mistakes in 
the bug report and arguing I deliberately raised the bug severity in hope to 
get faster attention. I've read the reportbug instructions and thought twice 
about what severity to choose and finally I choose what seemed the best fit 
based on my observations. Is the "grave" severity badly described in 
reportbug? Fix it! You are the developers after all!
</rant>

Anyway, I don't understand how that can be a bug of a different package, but, 
again, I take your word.

@David: I did not hack my code, I suppose that "-sh" is not to be looked for 
inside the code, but I think it's only the interpreter of the script. Maybe 
the users on that server have /bin/sh as default shell, I can't check right 
now. Maybe also I'm saying meaningless things...

Lucio.

Message #49 received at 498474-quiet@bugs.debian.org (full text, mbox, reply):

From: David Paleino <d.paleino@gmail.com>

To: 498474-quiet@bugs.debian.org

Cc: Lucio Crusca <lucio@sulweb.org>, Neil Williams <codehelp@debian.org>, Bash-Completion Developers <bash-completion-devel@lists.alioth.debian.org>

Subject: Re: [Bash-completion-devel] Bug#498474: moreinfo

Date: Thu, 11 Sep 2008 09:17:49 +0200

[Message part 1 (text/plain, inline)]

Hi Lucio,
please keep all us CCed :)

On Thu, 11 Sep 2008 02:28:18 +0200, Lucio Crusca wrote:

> Currently I have no access to the only box where I can reproduce this bug (it 
> is a fileserver at a customer's office). However I'll post here all the info 
> you ask as soon as I can access the server.

Ok, thanks.

> <rant>
> About the RC bug argument: I didn't even know that a grave bug is RC while an 
> important one isn't. I simply read the instructions that reportbug prints on 
> the screen: it says that the bug is grave when the package is completely 
> unusable, and that's exactly the situation on said server. Is it not a 
> bash-completion bug? Ok, I take your word, but please recognize it's not easy 
> for non-developers to identify the right package...

In fact, it's maintainer's duty to re-assign the bug if it's the wrong
package... don't worry :)

> a common user who takes himself the time to report a bug could even think
> it's a bash bug (though a minor one in that case).

And, in fact, many bugs reported to bash are re-assigned by bash's maintainer
to bash-completion :)

> I think you developers/maintainers should be thankful when someone reports a
> bug,

We *are* thankful!

> instead of complaining about mistakes in the bug report

Those *were* *not* complains... just suggestions.

> and arguing I deliberately raised the bug severity in hope to get faster
> attention.

It wasn't your case, it was a "general concept": it has happened that users
raised the severity to get more attention... I excuse myself (and Neil, I
suppose) if this wasn't clear :(

> I've read the reportbug instructions and thought twice about what severity to
> choose and finally I choose what seemed the best fit based on my
> observations. Is the "grave" severity badly described in reportbug? Fix it!
> You are the developers after all! </rant>

Probably it's badly described, after all ;)

> Anyway, I don't understand how that can be a bug of a different package, but, 
> again, I take your word.

bash_completion, besides the code in /etc/bash_completion itself, can read the
code from files in /etc/bash_completion.d/, and *any* package can install files
there (i.e. can provide completions for bash...)

> @David: I did not hack my code, I suppose that "-sh" is not to be looked for 
> inside the code, but I think it's only the interpreter of the script. Maybe 
> the users on that server have /bin/sh as default shell, I can't check right 
> now. Maybe also I'm saying meaningless things...

Oh well, that would print "sh" instead of "-sh" in the error messages... am I
wrong?

Please, provide the info Neil asked ASAP :)

Kindly,
David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

[signature.asc (application/pgp-signature, attachment)]

Message #54 received at 498474-quiet@bugs.debian.org (full text, mbox, reply):

From: Neil Williams <codehelp@debian.org>

To: David Paleino <d.paleino@gmail.com>

Cc: 498474-quiet@bugs.debian.org, Lucio Crusca <lucio@sulweb.org>, Bash-Completion Developers <bash-completion-devel@lists.alioth.debian.org>

Subject: Re: [Bash-completion-devel] Bug#498474: moreinfo

Date: Thu, 11 Sep 2008 09:54:22 +0100

[Message part 1 (text/plain, inline)]

On Thu, 2008-09-11 at 09:17 +0200, David Paleino wrote:
> Hi Lucio,
> please keep all us CCed :)

(Reply-all is handy with bug reports - especially when you have more
people than just the submitter and the maintainer involved.)

> On Thu, 11 Sep 2008 02:28:18 +0200, Lucio Crusca wrote:
> 
> > Currently I have no access to the only box where I can reproduce this bug (it 
> > is a fileserver at a customer's office). However I'll post here all the info 
> > you ask as soon as I can access the server.
> 
> Ok, thanks.

Also, Lucio, please add the output from this command:

$ ls -l /bin/sh

on the affected box. (that's the lower case L option to ls).

> > <rant>
> > About the RC bug argument: I didn't even know that a grave bug is RC while an 
> > important one isn't. I simply read the instructions that reportbug prints on 
> > the screen: it says that the bug is grave when the package is completely 
> > unusable, and that's exactly the situation on said server. Is it not a 
> > bash-completion bug? Ok, I take your word, but please recognize it's not easy 
> > for non-developers to identify the right package...

True, although you can generally take a hint if the package contains a
directory /etc/foo/bar.d/ or /etc/foo.d/ because those .d directories
are intended for system administrators or other packages to just "drop"
in their own files using an agreed syntax. Think /etc/init.d/ - no one
package owns all those files, each file is individually managed.
Reporting a bug against the package that creates /etc/init.d/ instead of
the package that puts a particular file into /etc/init.d/ does not make
sense once you understand how .d directories are generally used. That
isn't a Debian thing, that's a UNIX thing.

Probably the first thing to do with bugs like this is try to reproduce
it on a different system. If it cannot be reproduced and the package
uses a .d directory, you know the blame must lie elsewhere and you can
start to narrow down the list of possible packages by checking the
listing in the .d directory. In most cases, the filename with match the
package responsible, otherwise dpkg -S /etc/bash_completion.d/$filename
will identify which package put the file in place.

$ dpkg -S /etc/bash_completion.d/emdebian-qa
emdebian-qa: /etc/bash_completion.d/emdebian-qa

You can then fix this problem for your customer by moving a single file
out of the way:
# mv /etc/bash_completion.d/foo /home/user/bar/
(or move it to your USB stick etc. and test it at home.)

To test the file, start a new terminal window and use:
. /home/user/bar/foo

exit that shell, then comment out each block in the file one at a time
and retest. When you have identified which block of code is responsible,
you can put the file back with the appropriate section commented out and
the customer will only then be missing a single completion.

This is all standard bug-triage work that most users will already be
doing. Bugs are far more likely to get fixed if a little bit of testing
is done on the affected system *before* filing a bug.

(Maybe reportbug should hint about something like that, or maybe
bash-completion {or bash} can add a presubj file to reportbug to suggest
something like that. Hmmm, this bug could end up being cloned twice.)

As I've shown, bash completion works perfectly well with and without the
bash-completion package on my test systems. I'm beginning to think that
bash should take more responsibility for checking the contents
of /etc/bash_completion.d/ and documenting how to use it.

> In fact, it's maintainer's duty to re-assign the bug if it's the wrong
> package... don't worry :)

Agreed. Users can but the maintainer is the one who needs to if nobody
else does. To do that, the maintainer needs that listing I asked for, so
once you have a connection to that server and send in the listing,
things will be a lot easier for everyone.

> > a common user who takes himself the time to report a bug could even think
> > it's a bash bug (though a minor one in that case).
> 
> And, in fact, many bugs reported to bash are re-assigned by bash's maintainer
> to bash-completion :)
> 
> > I think you developers/maintainers should be thankful when someone reports a
> > bug,
> 
> We *are* thankful!

Ditto.

> > instead of complaining about mistakes in the bug report
> 
> Those *were* *not* complains... just suggestions.

Hence the /me prefix - hints, gentle pointers in the right direction.

> > and arguing I deliberately raised the bug severity in hope to get faster
> > attention.
> 
> It wasn't your case, it was a "general concept": it has happened that users
> raised the severity to get more attention... I excuse myself (and Neil, I
> suppose) if this wasn't clear :(

Guess I missed a smilie in that case. It was not my intention to make a
personal accusation, just comment on the general problem. Each case can
have a different cause - this time it was a lack of understanding
about /etc/bash_completion.d/ and how it is used. If you had known
about .d and how it is used, you may have passed the suspect file to
reportbug and reportbug would have identified the right package from
that information (and it would probably not have been bash_completion
because even after installing bash-completion alongside all the other
completion scripts in /etc/bash_completion.d/ I have no problems with
completion).

> > I've read the reportbug instructions and thought twice about what severity to
> > choose and finally I choose what seemed the best fit based on my
> > observations. Is the "grave" severity badly described in reportbug? Fix it!
> > You are the developers after all! </rant>
> 
> Probably it's badly described, after all ;)

I'm not sure reportbug can do that much more - it does need to cover all
packages after all. The problem is that this is not a bug in
bash-completion, it is a bug in a package that uses bash-completion. As
such, it is unlikely that the package at fault absolutely relies upon
bash-completion and cannot possibly operate without it. Therefore, once
the correct package is identified, the fix would be to simply remove the
relevant file from /etc/bash_completion.d/ to restore full bash
completion for all other packages. With a little understanding of how
a .d directory is used, this bug would have been easier to file using
reportbug with the existing instructions. reportbug would have
identified the package responsible for the problematic file and the
severity would have been lower because you would be able to see that it
is only one part of package 'foo' that is broken.

Therefore, this is a wishlist bug in bash-completion seeking better
documentation (an explicit manpage for /etc/bash_completion.d/ or a
general manpage for bash-completion that clearly
documents /etc/bash_completion.d/ and explains that other packages put
files into it.). The bash manpage is extremely long (as one would
expect) but I couldn't find any mention of /etc/bash_completion.d/ in
it. (/etc/bash_completion.d/ works even without bash-completion itself
being installed so maybe this bug is a bug in bash rather than
bash-completion after all and could be reassigned as wishlist against
bash, preferably asking for a separate manpage to cover completion and
bash_completion.d/.) That is a choice left to the maintainer. ;-)

At the same time, the bug needs to be cloned and reassigned to whichever
package is responsible for the broken file in /etc/bash_completion.d/ -
depending on the package, this could be a bug of severity important,
normal or minor.

In no way is this an RC bug (severity critical, grave or serious).

The bit about breaking unrelated software does not apply to this bug - a
bug in a bash_completion script may well affect completion for other
packages but that is related software, not unrelated. True, maybe bash
could be more intelligent about parsing files
in /etc/bash_completion.d/, maybe dh_bash-completion should be extended
to support error parsing during builds and be brought fully within
debhelper so that it can be made a compulsory step in using
bash_completion (I have several completion scripts and have never used
dh_bash-completion because it means build-depending on bash-completion).
None of that detracts from the fact that bash-completion, as a package,
is not buggy in this respect.

> > Anyway, I don't understand how that can be a bug of a different package, but, 
> > again, I take your word.
> 
> bash_completion, besides the code in /etc/bash_completion itself, can read the
> code from files in /etc/bash_completion.d/, and *any* package can install files
> there (i.e. can provide completions for bash...)

Hence the list of files in my request and the comment that any of those
*packages* could not be the cause of this bug because I have lots of
bash completion in usage and the bash completion code itself is *not*
buggy in this respect.

Some package has dropped a file into /etc/bash_completion.d/ on your
test system that is not installed on my system (or David's by the sound
of it) and it is one of these files that is buggy. Identifying which
packages you have installed that I do not have installed is a key part
of identifying the cause of this bug. Moving the ones that differ aside,
one by one, will fix your problem.

Files in /etc/bash_completion.d/ map directly to other packages where
this bug could be reassigned. The fact that bash_completion itself is
*not* broken on other systems means that the reportbug severity was a
mistake, borne out of a misunderstanding of what .d directories do and
how bash completion works.

> Please, provide the info Neil asked ASAP :)

Ditto.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

[signature.asc (application/pgp-signature, inline)]

Message #65 received at 498579-done@bugs.debian.org (full text, mbox, reply):

From: David Paleino <d.paleino@gmail.com>

To: 498579-done@bugs.debian.org

Subject: Closing

Date: Thu, 17 Sep 2009 09:50:45 +0200

[Message part 1 (text/plain, inline)]

Hello,
unreproducible, more info needed but not provided, probably caused by calling
bash as /bin/sh, closing it.

David

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.