Description of problem:
I installed bash-completion so I could get autocompletion when trying to install packages via yum. While I now can tab complete if I su first, I get nothing when I try to tab complete packages if I try to sudo yum install whatever.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try to tab complete #yum install optip, it correctly completes to optipng
2. Try to tab complete $sudo yum install optip, nothing happens
No tab completion
Bash-complete will be included in base for rawhide, it would be awesome if it worked with sudo. See - https://fedorahosted.org/fesco/ticket/689
I found a blog post from 2 years ago that showed me I could fix it if I type "complete -cf sudo" into terminal, I can now tab complete while using sudo. Can we include this functionality by default?
I cannot reproduce, it works just fine for me. Note that yum install completions do not include packages that you already have installed, maybe that's why?
For "sudo yum install optip" to complete to optipng.$arch, this plain yum command (no completion involved) should list it:
yum -d 0 -C list available "optip*"
If it is listed but still not completed, do a "set -x" in a shell, invoke the completion that does not work, capture the output and attach it here.
The FESCO ticket is somewhat confusing, I'll post some notes to it.
$yum -d 0 -C list available "optip*" results in -
[Errno 13] Permission denied: '/var/cache/yum/x86_64/16/fedora/8e5f7c264cbd50659a18cd4f87fe75ea728fdc187d4e5e041898070c9dccf5e8-comps-f16.xml'
$sudo yum -d 0 -C list available "optip*" results in -
Error: No matching Packages to list
$yum -d 0 -C list available "gcc*" results in the same permission denied message.
$sudo yum -d 0 -C list available "gcc*" results in -
gcc-gfortran.i686 4.6.2-1.fc16 fedora
gcc-gfortran.x86_64 4.6.2-1.fc16 fedora
gcc-gnat.x86_64 4.6.2-1.fc16 fedora
gcc-go.x86_64 4.6.2-1.fc16 fedora
gcc-java.x86_64 4.6.2-1.fc16 fedora
gcc-objc.x86_64 4.6.2-1.fc16 fedora
gcc-objc++.x86_64 4.6.2-1.fc16 fedora
gcc-plugin-devel.i686 4.6.2-1.fc16 fedora
gcc-plugin-devel.x86_64 4.6.2-1.fc16 fedora
gcc-python-plugin-docs.x86_64 0.6-4.2.fc16 fedora
gcc-python2-debug-plugin.x86_64 0.6-4.2.fc16 fedora
gcc-python2-plugin.x86_64 0.6-4.2.fc16 fedora
gcc-python3-debug-plugin.x86_64 0.6-4.2.fc16 fedora
gcc-python3-plugin.x86_64 0.6-4.2.fc16 fedora
gccxml.x86_64 0.9.0-0.6.20110211.fc16 fedora
Should I have to change the permissions of my yum cache? Seems like that's what I need to do. Optipng was just an example, I haven't gotten yum to autocomplete anything while using sudo, while it autocompletes just fine if I su first. If I put in "complete -cf sudo" in a new terminal and then use sudo with yum, it looks like I can autocomplete installed packages, but a double tab will not list possibilities, it just completes to gcc, libreoffice, optipng, etc. Once I close that terminal, I'll have to issue that command again for it to work like that. I guess complete -cf sudo doesn't do what I was hoping it did.
I linked the FESCO ticket just to show that bash-completion will be installed by default, that's unrelated to what I'm experiencing here.
Hi Ville, I run Fedora 16, I installed bash-completion today and was able to reproduce Matt's results. If I type:
sudo yum install optip
And hit tab, nothing happens at all. No matter how many times I hit tab. If I type:
sudo su -
sudo yum install optip
And hit tab, I get completion of the package name.
I ran 'yum -d 0 -C list available "optip*"' as you instructed and received the same permission error that Matt did.
WRT the FESCo ticket, just because bash-completion is in @Base does not mean it gets installed by default. It has to be flagged as mandatory for that to happen, and since it was not installed on my F16 system by default, I am guessing that is not the case at the moment?
Thank you so much for the impressively quick response and helping us out with this issue, it is greatly appreciated.
Regarding being installed by default or not, I haven't installed F-16 from scratch yet so I cannot verify it, but if being in the base group as '<packagereq type="default">bash-completion</packagereq>' does not result in it being installed by default, I think something (either software or terminology) is broken somewhere. Flagging it as mandatory seems overkill to me -- I don't know why people shouldn't be given the choice to not install it if they so desire.
Regarding the rest of this bug, it's a (long standing) problem in yum; there's nothing bash-completion can do about it. I'm not sure how to describe it better than there are still various problems, at least those "permission denied" ones running various yum commands as non-root in some scenarios (completions for "sudo yum ..." are not run as root but the original user), IIRC especially with yum -C -> reassigning to yum.
Unfortunate that yum won't let us do this, thanks for your help though!
I talked to geppetto a bit about this bug on IRC; here's some more information for those following along:
1) The problem is that the completion uses yum -C … which uses the root cache
2) The yum devs will probably fix it by just changing a bunch of yum stuff so that yum as a user always uses the user dirs.
I haven't gotten any workarounds to work yet (besides simply "sudo su -" then running yum with tab complete)
One (poor) workaround is to first run some yum commands as the non-root user without -C to "seed" the user dirs, for example "yum list all", "yum repolist", "yum grouplist" etc, then try the completions.
I can add to this,
Using Fedora 16, Gnome Terminal or Guake I get issues using tab for auto-completion on many commands including mount.
EX1: mount /stor/n[tab]etshare/s[tab]hare/I[tab]SOs //- works fine (but can't mount drive)
EX2: sudo mount /stor/n[tab] //- returns no values (have to manually enter info)
EX3: sudo mount /s[tab]tor (with a space at the end) //- returns the first directory but no further directories
This is mostly a default setup and if I get time I will throw a fresh install on another PC and perform the same tests there. However I think this issue may be more prevalent than just yum.
Changed summary to reflect the originally reported issue.
Please file specific new bugs about new problems so we don't end up with everything lumped here. sudo and mount completion not working properly together is a known issue which will as far as I know be addressed at least to some extent in the upcoming bash-completion 2.0rc1 release which will appear in rawhide soon.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.