Bug 267788 – app-shells/bash-completion: clean handling of extglob and other shopt settings

• Product: Gentoo Linux
• Status: RESOLVED OBSOLETE

[Description Martin von Gagern 2009-04-28 16:31:27 UTC]

Some bash completions require extglob to be set. Some of them set it when defining their completion functions, some don't, but most seem to hope it will be set when the function gets executed. monotone tries to clean up after its work, but that attempt is broken for several reasons, see bug #259835.

It would be great to improve the situation, i.e. use extglob in completion functions without polluting the user environment. Today I was contemplating this whole mess, spending a bit of time on freenode in #bash, and someone pointed out that a subshell would be suitable.

With that piece of information, I cooked up some neat solution. The idea is to have the following line at the beginning of every bash completion function using extglobs:

_my_completion_function() {
  _with_shopt extglob || return
  # completion implementation using extglobs
}

The magic _with_shopt function would be implemented in this way:

_with_shopt () { 
    shopt -q "$@" && return 0
    local IFS=$'\n'
    COMPREPLY=($(
        shopt -s "$@"
        ${FUNCNAME[1]}
        IFS=$'\n'
        echo "${COMPREPLY[*]}"
    ))
    return 1
}

It first checks for the requested option(s), and returns 0 if all are set, allowing the function to complete unimpeded. If at least one is missing, it will execute the calling function in a subshell environment, where the option has been enabled.

Communication between those two is via stdout of the subprocess, formatted as one array element per line. The child sends its compreply, generated by the completion function in the correct environment, to its parent, who turns it back into an array. Of course this prevents linebreaks as parts of the completion words, but I don't believe I care.

I have tested this function with some other custom functions, and with mtn as described in bug #259835. Works well enough. I would wish for this function to be made available in /usr/share/bash-completion/.pre as a first step, and then completion functions can be converted to use it. To find out where:

  egrep '[?*+@!]\(' /usr/share/bash-completion/*

In bug #259835, a discussion on the gentoo-dev mailing list was suggested, but I feel more comfortable in bugzilla, especially as I'm not subscribed to said list. I also believe there are few people who actually care enough about bash completion to give any valuable input, so a bug assigned to the bash-completion maintainers is probably more likely to yield tangible results. If you disagree, and think there should be a discussion per mail, please have some Gentoo developer start it.

[Comment 1 Jeremy Olexa (darkside) (RETIRED) 2009-04-28 16:48:14 UTC]

I don't have a problem with the change, however, you will have to get upstream to accept your patches. I am not about to maintain a slew of downstream patches for this. Sorry.

[Comment 2 Martin von Gagern 2009-04-28 17:27:00 UTC]

(In reply to comment #1)
> I don't have a problem with the change, however, you will have to get upstream
> to accept your patches. I am not about to maintain a slew of downstream patches
> for this. Sorry.

I understand. Submitted upstream, see URL.

[Comment 3 Jeremy Olexa (darkside) (RETIRED) 2009-04-28 17:35:32 UTC]

Great, thanks for your research and work here.

[Comment 4 Christian Faulhammer (RETIRED) 2009-11-03 19:43:23 UTC]

(In reply to comment #2)
> (In reply to comment #1)
> > I don't have a problem with the change, however, you will have to get upstream
> > to accept your patches. I am not about to maintain a slew of downstream patches
> > for this. Sorry.
> 
> I understand. Submitted upstream, see URL.

 What is the outcome now?

[Comment 5 Martin von Gagern 2009-11-03 19:55:36 UTC]

(In reply to comment #4)
>  What is the outcome now?

No reply at all on the upstream bug report, as you can see. I've tried to get their attention in the corresponding IRC channel a few times, but no success there either. Maybe one of you has a better idea or regular contact with them?

In the meantime, I've found that extglob has to be enabled at the time a function is defined as well, not only at execution time. For some consructs, like [[ $var == @(some|pat|tern) ]], having it set at definition time is enough, while for others, like case, the extglob shopt has to be set at runtime as well. http://thread.gmane.org/gmane.comp.shells.bash.bugs/13518

I've had a discussion about this with the bash maintainer, Chet Ramey. The difference between [[ == ]] and case is deliberate and going to stay. He suggests that bashcomp functions should simply use extglob patterns, and it's up to the users using such completions to have extglob on. I'm not sure I agree, I'd still prefer functions to work no matter the local shopt settings.
http://thread.gmane.org/gmane.comp.shells.bash.bugs/13518/focus=13535

[Comment 6 Daniel Black (RETIRED) 2010-07-18 04:26:26 UTC]

*** Bug 259835 has been marked as a duplicate of this bug. ***

[Comment 7 Michał Górny 2017-07-02 22:33:44 UTC]

Feel free to reopen with an update if there's anything that still needs doing here.