Bug 851908

Can not reproduce

 werner@linux:~> echo $PA<TAB>
 $PACKDIR  $PAGER    $PATH   
 werner@linux:~> complete -p | grep echo
 complete -F _minimal echo
 werner@linux:~> compopt -D
 compopt +o bashdefault +o default +o dirnames +o filenames +o nospace +o plusdirs -D
 werner@linux:~> rpm -q bash-completion
 bash-completion-2.1-3.1.2.noarch

You're right, I didn't have bash-completion installed.

It seems it was uninstalled during upgrade, because I'm positive it had been there before...

But it has to work without bash-completion too. Not having this should not break the bash default.

Creating an empty $HOME/.bash.expert also fixes the problem. So there is definitely something broken in /etc profiles or bash setup.

(In reply to comment #3)

Then debug this please or give me more informations like

      complete -p | grep echo

beside this: why should bash-completion not be installed?

(In reply to comment #4)
> Then debug this please or give me more informations like

I've tracked it down, this is the change breaks it:


----------
commit 992b34c839eec01b452571541d889af31e1d2502
Author: root <root@tenfore.site>
Date:   Thu Oct 10 02:40:28 2013 +0200

    zypper dup (factory, 13.1 RC1)

diff --git a/profile.d/complete.bash b/profile.d/complete.bash
index 1471754..ab86506 100644
--- a/profile.d/complete.bash
+++ b/profile.d/complete.bash
@@ -672,5 +672,20 @@ complete ${_def} ${_file}  -F _ls_         ls ll la l ls-l lf
 unset _def _dir _file _nosp

 #
+# info bash 'Command Line Editing' 'Programmable Completion'
+#
+if ! type -t _completion_loader &> /dev/null ; then
+    _completion_loader ()
+    {
+       local fallback=(-o default -o bashdefault -o filenames)
+       local dir=/usr/share/bash-completion/completions
+       local cmd="${1##*/}"
+       . "${dir}/${cmd}" &>/dev/null && return 124
+       complete "${fallback[@]}" ${cmd} &>/dev/null && return 124
+    }
+    complete -D -F _completion_loader
+fi
+
+#
 # End of /etc/profile.d/complete.bash
 #
--------

BTW removing that block also solves other issues like not completing paths after ":", like this:
PATH=/usr/bin:/usr/lo<TAB>
which is also very annoying for rsync etc.


(In reply to comment #4)
> 
> beside this: why should bash-completion not be installed?

Don't know. Why I should have it? I've never had this installed and it's AFAIK not installed per default.

I'll *not* remove that as this will load automatically completions for the commands used.  Otherwise this will cause a reopen of bug #821411.

Maybe the defaults in the fallback variable are wrong or should removed ... please try out what happens if fallback is empty with

     local fallback=()

Chagne the shell function to become as follows

    _completion_loader ()
    {
        local dir=/usr/share/bash-completion/completions
        local cmd="${1##*/}"
        . "${dir}/${cmd}" &>/dev/null && return 124
        complete -o default -o bashdefault "${cmd}" &>/dev/null && return 124
    }

This seems to solve the problem -> submit request #211401

Yes, comment #7 works now for the variable completion problem (comment #1)

About the colon problem (comment #4). Should I open another bug report or could
you just look at it? In comment #4 I was wrong, it's not related to the same
function. Touching $HOME/.bash.expert is "fixing" it.


(In reply to comment #6)
> I'll *not* remove that as this will load automatically completions for the
> commands used.  Otherwise this will cause a reopen of bug #821411.

OK but wouldn't it be
"completion broken for any command" vs. "missing a few particular completions".
IMO adding particular completions should not break other ones.

Isn't /usr/share/bash-completion/completions/ already sourced by the
bash-completion package? Wouldn't it be ok to require installed bash-completion
to source that directory?

This is an autogenerated message for OBS integration:
This bug (851908) was mentioned in
https://build.opensuse.org/request/show/211399 Factory / aaa_base
https://build.opensuse.org/request/show/211401 13.1 / aaa_base

(In reply to comment #9)

> About the colon problem (comment #4). Should I open another bug report or could
> you just look at it? In comment #4 I was wrong, it's not related to the same
> function. Touching $HOME/.bash.expert is "fixing" it.

I'm not arware of a colon problem ... and comment #4 is my own comment .. ?

>  Isn't /usr/share/bash-completion/completions/ already sourced by the
> bash-completion package? Wouldn't it be ok to require installed bash-completion
> to source that directory?

No it is not as such would heavily increase the startup time of the bash as there are a huge number of files. Most of them are provided by packages which do provide their own completion for tool in the package. This is perpendicular to the bash-completion package.

(In reply to comment #11)
> (In reply to comment #9)
> 
> > About the colon problem (comment #4). Should I open another bug report or could
> > you just look at it? In comment #4 I was wrong, it's not related to the same
> > function. Touching $HOME/.bash.expert is "fixing" it.
> 
> I'm not arware of a colon problem ... and comment #4 is my own comment .. ?

Sorry, I mean comment #5:
[...] not completing paths after ":", like this:
  PATH=/usr/bin:/usr/lo<TAB>
which is also very annoying for rsync etc.


> >  Isn't /usr/share/bash-completion/completions/ already sourced by the
> > bash-completion package? Wouldn't it be ok to require installed bash-completion
> > to source that directory?
> 
> No it is not as such would heavily increase the startup time of the bash as
> there are a huge number of files. Most of them are provided by packages which
> do provide their own completion for tool in the package. This is perpendicular
> to the bash-completion package.

I understand but I'm missing an easy way to prevent other unrelated packages from changing my bash setup. The $HOME/.bash.expert solution is to much and also does not work globally for all users.

(In reply to comment #12)

> Sorry, I mean comment #5:
> [...] not completing paths after ":", like this:
>   PATH=/usr/bin:/usr/lo<TAB>
> which is also very annoying for rsync etc.

This *is* a job for a complete function for rsync as the bash default not the readline default will not do this (AFAIK).

> I understand but I'm missing an easy way to prevent other unrelated packages
> from changing my bash setup. The $HOME/.bash.expert solution is to much and
> also does not work globally for all users.

Hmmm ... if you want to have plain TAB completion you may add

       complete -r

in ~/.bashrc ... on the other hand if one of the completion below

       /usr/share/bash-completion/completions/

does bother then run

       rpm -qf /usr/share/bash-completion/completions/<file>

the see the package and open a bug against this package.

(In reply to comment #13)
> > [...] not completing paths after ":", like this:
> >   PATH=/usr/bin:/usr/lo<TAB>
> > which is also very annoying for rsync etc.
> 
> This *is* a job for a complete function for rsync as the bash default not the
> readline default will not do this (AFAIK).

No it's not rsync related. Colon is a standard path separator in UNIX. It works as expected in default bash setup. It always worked in openSUSE <= 12.3.

> ... on the other hand if one of the completion below
> 
>        /usr/share/bash-completion/completions/
> 
> does bother then run
> 
>        rpm -qf /usr/share/bash-completion/completions/<file>
> 
> the see the package and open a bug against this package.

It's too much work for me.
Since 13.1 I see so many little but annoying problems ... that's why I want to try to get only the basic things fixed here. I was thinking about this since 2 months whether it's worth to start writing bug reports or better to use my own bashrc and profile from scratch (probably getting a lot other kind of problems).

(In reply to comment #12)

> [...] not completing paths after ":", like this:
>   PATH=/usr/bin:/usr/lo<TAB>

Got it. It came with osc

diff --git a/profile.d/osc.sh b/profile.d/osc.sh
index 6148b40..77156ad 100644
--- a/profile.d/osc.sh
+++ b/profile.d/osc.sh
@@ -1,6 +1,7 @@
 test -z "$BASH_VERSION" && return
 complete -o default _nullcommand >/dev/null 2>&1 || return
 complete -r _nullcommand >/dev/null 2>&1         || return
+COMP_WORDBREAKS="${COMP_WORDBREAKS//:}"
 test -s /usr/share/osc/complete && complete -o default -C /usr/share/osc/complete osc
 test -s /usr/lib64/osc/complete && complete -o default -C /usr/lib64/osc/complete osc
 test -s /usr/lib/osc/complete   && complete -o default -C /usr/lib/osc/complete osc


This needs to be reverted.
BTW COMP_WORDBREAKS was not even exported, so even more confusing that there was no problem in a subshell.

(In reply to comment #15)

I agree that the real bug is the colon as the subproject separator in OBS.
No idea who has choosen this (without asking the bash maintainer;)

Nevertheless not only I'm using the completion for the osc command but many other developers do ;)

Currently I do not have an idea how to solve this to make completion for osc and rsync do work both.

I disagree with "the real bug", if bash can detect what the completed string is, but failing in expanding it, it is an inconsistent behaviour inside of bash at least

in any case, this line came via git commit of Werner Fink for osc. So, if you want to change it, please send another pull request to osc.

IMHO the completion can never work really without the context, the PATH seperator list (all : are seperators) is different to rsync (only first : is a seperator), osc (none are seperators) or any URL completion (first one of protocol is seperator, second one may be port seperator or belongs to path depending on the place).

(In reply to comment #17)

@ Adrian: it *is* a bug to choose a colon as subproject separator in OBS!

Do you know how COMP_WORDBREAKS works?  You can not select COMP_WORDBREAKS based on the command you're currently using. This variable is readline specific:

       COMP_WORDBREAKS
              The  set of characters that the readline library treats as word
              separators when performing word completion.  If COMP_WORDBREAKS
              is unset, it loses its special properties, even if it  is
              subsequently reset.

that is it work for all commands *before* the completion of the bash its self will work.

Well, using colon was just a very unlucky decision. But I'm not the right person to revert this upstream. However osc users (like me) want to work around the colon issues. Just installing the osc rpm package must not break the better default systemwide for all users.

BTW the usefulness of osc completion scripts is debatable anyway. IMO it would be better to provide the files as they are but not to source them per default.
See also
http://comments.gmane.org/gmane.linux.suse.opensuse.buildservice/20378

(In reply to comment #19)

Hmmm ... any suggestions or better working patches to upgrade the completion script for osc are welcome.  As I'm really busy with systemd I'll not time to play with and extend my osc completion script.  But note that it should not only work with bash but also for other shells like zsh and tcsh :)

My "fix" without spending time would be like this:
mv  /etc/profile.d/osc.csh  /usr/lib/osc_profile.csh
mv  /etc/profile.d/osc.sh  /usr/lib/osc_profile.sh
People who like it can source them in their ~/.profile. If you agree i can submit it.

For osc upstream I would suggest to do this whenever there is time for it:
1. Add configurable disable/enable network usage.
2. Add configurable project completion because even cached it may be too slow for some user's taste.
3. Fix for users without osc account (check ~/.oscrc). Note, because we have to check ~/.oscrc anyway it could be a good place to add other completion options there.
4. Let the whole thing work without touching COMP_WORDBREAKS (maybe it does already!?). I guess you removed ":" only to have more comfortable usage of coreutils within the osc checkouts. Actually this has nothing to do with the osc completion itself.
5. Add cronjob to refresh project cache asynchronously.
6. If the slow show stoppers are disabled by default and does not affect non-osc related completions then you could move it back to. /etc/profile.d/

It does not work with colon

  werner@linux:~> osc ls openSUSE:<TAB>
  werner@linux:~> osc ls openSUSE:openSUSE:

also

  werner@linux:~> osc ls openSUSE:13<TAB>
  werner@linux:~> sc ls openSUSE:openSUSE:13.1

which is very annoying if you want list the content of a project and/or package.

Yes, but the problem here is at least an inconsistant behaviour. If it can not detect the string to expand and just does nothing, well, fine.

But here it does detect string correctly (not using : as seperator), but it does replace it wrong (using : as seperator).

This is definitive an inconsistant behaviour of bash (or it's completion scripts) itself.

(In reply to comment #23)

Ahmm ... this is the libreadline *before* the completion or a completion script or completion shell function of the bash tries to handle this!

(In reply to comment #24)
> (In reply to comment #23)
> 
> Ahmm ... this is the libreadline *before* the completion or a completion script
> or completion shell function of the bash tries to handle this!

However zsh is able to do it way better.
On the other hand colons are still one of the most evil characters for file names. They are IMO even worse than spaces or tabs. For example usually you can't build automake/libtool based tar balls if their absolute path contains a colon. Because such paths can't be used in $PATH or $LD_LIBRARY_PATH etc.. Moreover this is really unlucky because osc working copies usually contain such source tar balls and it would be very natural to untar and build them locally where they are. Another use case would be getbinaries, unrpm, PATH=xyz to try something out quickly.

Created attachment 572582 [details]
0001-Work-around-the-libreadline-colon-trouble-if-COMP_WO.patch

This may help for osc ... nevertheless now user do not see the full project in the completion return anymore but only the subproject.

I've send this to opensuse-buildservice@opensuse.org

openSUSE-SU-2013:1955-1: An update that solves one vulnerability and has one errata is now available.

Category: security (moderate)
Bug References: 843230,851908
CVE References: CVE-2013-3713
Sources used:
openSUSE 13.1 (src):    aaa_base-13.1-16.26.1

your fix is not pushed to the 13.1 branch in git. please push otherwise the change gets lost on next update.

(In reply to comment #29)

How this can be done?