Summary: | www-client/surfraw-2.2.5 bash_completion syntax error | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | urcindalo <urcindalo> |
Component: | Current packages | Assignee: | James Rowe <jnrowe> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jer |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | surfraw-fix_standalone_completion.patch |
Description
urcindalo
2009-07-15 06:19:45 UTC
That is definitely an odd error, it looks like somehow bash's extglob option has become unset. It is explicitly set by the .pre script because the whole of the bash completion package makes extensive use of it, so this shouldn't be happening. Are you sure you've not unset it yourself for some other reason? I can't duplicate this error myself without manually breaking my environment. I guess one "solution" could be to forcibly set extglob in the completion script, but it is worth noting that this is not normally needed and none of the other extglob dependant scripts do this. I'd much rather figure out what is actually causing this than just tacking on a 'shopt -s extglob'. As requested by James, please reopen this bug when you provide the output of the following command: grep shopt ~/.bash* /etc/bash/* /etc/profile /etc/profile.d/ urcindalo, also the output of "grep shopt.*extglob /usr/share/bash-completion/*" may be helpful, in case there is a completion script from a package I've not found that is causing this. OK. Here they are: ========== ~ $ grep shopt ~/.bash* /etc/bash/* /etc/profile /etc/profile.d/ /etc/bash/bashrc:shopt -s checkwinsize /etc/bash/bashrc:shopt -s histappend ~ $ grep shopt.*extglob /usr/share/bash-completion/* /usr/share/bash-completion/subversion:# pattern matching enabled (use 'shopt -s extglob progcomp' to enable /usr/share/bash-completion/subversion:shopt -s extglob ~ $ eix -I subversion [I] dev-util/subversion Available versions: ~1.4.6-r2!t[1] 1.5.5!t 1.5.6!t ~1.6.1!t 1.6.2 ~1.6.2-r10 ~1.6.3 ~1.6.3-r10 {apache2 bash-completion berkdb ctypes-python debug doc dso elibc_FreeBSD emacs extras gnome-keyring java kde nls nowebdav perl python ruby sasl svnserve test vim-syntax webdav-neon webdav-serf} Installed versions: 1.6.2(11:21:03 29/06/09)(bash-completion berkdb java nls perl python ruby sasl webdav-neon -apache2 -ctypes-python -debug -doc -dso -elibc_FreeBSD -emacs -extras -gnome-keyring -test -vim-syntax -webdav-serf) Homepage: http://subversion.tigris.org/ Description: Advanced version control system [1] (layman/ecatmur) ~ $ ========= I've added my subversion version because of the output of the second grep command. Hope this helps. Also, if it is of any value, I understood nothing in comment #2... :oops: :-D Thanks in advance. Requested info provided. Thanks for the updated information. (In reply to comment #4) > Also, if it is of any value, I understood nothing in comment > #2... :oops: :-D I take it you meant my explanation which was actually comment #1? That's okay, let me try to explain a little better :) The syntax used in the surfraw completion script is in fact valid bash syntax, it just depends on bash's extglob option being turned on. extglob provides bash with extended pattern matching abilities, which is what the @(...|...) syntax is. As the bash-completion package makes extensive use of that feature it is forced on in /usr/share/bash-completion/.pre , you can see for yourself just how often it is used by "grep '@(' /usr/share/bash-completion/*". The only reason I'm know of that could cause you to see that error is if somehow the option has been disabled, I was asking whether you had done that for some other reason. That is also why I wanted to see your bash configs. Unfortunately, even with your extra information I still can't see what is causing it yet, so thanks for your patience. In the meantime the quick workaround would be to place "shopt -s extglob" at the top of the surfraw completion script. Could you please post the output of "grep shopt /etc/profile.d/*". There was a missing * in the comment above, which was entirely my fault. And the output of "shopt" in any shell that is exhibiting this bug may also be helpful. Thanks > I take it you meant my explanation which was actually comment #1? That's > okay, let me try to explain a little better :) Thanks. Yes, I meant #1. I took for granted if mine was #1 yours was #2... .-D > ...you can see for yourself just how > often it is used by "grep '@(' /usr/share/bash-completion/*". OK. I even show you the output. Only subversion and surfraw make use of it: ===== ~ $ grep '@(' /usr/share/bash-completion/* /usr/share/bash-completion/subversion: if [[ $opt == @(dir|all) && -d "$f" ]] ; then /usr/share/bash-completion/subversion: elif [[ $opt == @(file|all) ]] ; then /usr/share/bash-completion/subversion: if [[ $prev == @($optsParam) ]] ; then /usr/share/bash-completion/subversion: if [[ $prev == @(<|>|>>|[12]>|[12]>>) ]] ; then /usr/share/bash-completion/subversion: && ( $opt != -* || $opt == @(${specOpts// /|}) ) ]] /usr/share/bash-completion/subversion: [[ $cmd == @($propCmds) ]] && isPropCmd=1 /usr/share/bash-completion/subversion: [[ $cmd == @($psCmds) ]] && isPsCmd=1 /usr/share/bash-completion/subversion: [[ $cmd == @(${helpOpts// /|}) ]] && cmd='help' /usr/share/bash-completion/subversion: [[ $prop == @(${revProps// /|}) ]] && isRevProp=1 /usr/share/bash-completion/subversion: if [[ $c == $cur* && ( ! $seen || $c != @($seen) ) ]] /usr/share/bash-completion/subversion: files=$($status $cs| _svn_grcut '@([MADR!]*| M*|_M*)') /usr/share/bash-completion/subversion: files=$($status $cs| _svn_grcut '@(??L*|?????[KOTB]*)') /usr/share/bash-completion/subversion: files=$($status $cs| _svn_grcut '@(?C*|C*)') /usr/share/bash-completion/subversion: if [[ $cmd == @($propCmds) && \ /usr/share/bash-completion/subversion: $prop == @(svn:ignore|svn:externals) ]] ; then /usr/share/bash-completion/subversion: if [[ $acceptOpt == @(edit|launch) ]] ; /usr/share/bash-completion/subversion:complete -F _svn -o default -X '@(*/.svn|*/.svn/|.svn|.svn/)' svn /usr/share/bash-completion/subversion: if [[ ${COMP_WORDS[1]} != @($helpCmds) ]] && \ /usr/share/bash-completion/subversion: [[ ${COMP_WORDS[COMP_CWORD-1]} == @($optsParam) ]] ; then /usr/share/bash-completion/subversion: if [[ $opt == @($optsParam) ]] ; then /usr/share/bash-completion/subversion: if [[ ${COMP_WORDS[1]} != @($helpCmds) ]] && \ /usr/share/bash-completion/subversion: [[ ${COMP_WORDS[COMP_CWORD-1]} == @($optsParam) ]] ; then /usr/share/bash-completion/subversion: if [[ $opt == @($optsParam) ]] ; then /usr/share/bash-completion/surfraw: elif [[ $prev == @(alioth|deb@(bugs|contents|packages|pts|sec)|freshmeat|fsfdir|sourceforge) ]] ~ $ ===== > Could you please post the output of "grep shopt /etc/profile.d/*". Sure. It shows nothing. I don't know if that's correct or not. ===== ~ $ grep shopt /etc/profile.d/* ~ $ ===== > And the output of "shopt" in any shell that is exhibiting this bug may also > be helpful. I run an almost stable AMD64 box and my shell is just bash: ===== ~ $ shopt cdable_vars off cdspell off checkhash off checkwinsize on cmdhist on compat31 off dotglob off execfail off expand_aliases on extdebug off extglob off extquote on failglob off force_fignore on gnu_errfmt off histappend on histreedit off histverify off hostcomplete on huponexit off interactive_comments on lithist off login_shell off mailwarn off no_empty_cmd_completion off nocaseglob off nocasematch off nullglob off progcomp on promptvars on restricted_shell off shift_verbose off sourcepath on xpg_echo off ~ $ eix -I bash [I] app-shells/bash Available versions: 3.1_p17 3.2_p39 ~3.2_p48 ~3.2_p48-r1 ~4.0_p10 ~4.0_p10-r1 ~4.0_p17 ~4.0_p17-r1 ~4.0_p24 {afs bashlogger examples net nls plugins vanilla} Installed versions: 3.2_p39(17:21:03 08/04/09)(nls plugins -afs -bashlogger -examples -vanilla) Homepage: http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html Description: The standard GNU Bourne again shell ~ $ ===== As you can see, extglob is off. Since only subversion and surfraw seem to make use of extglob extensions, and I have installed surfraw only recently, is it possible that suvbersion-1.6.2 had disabled it by default? It is the stable version for amd64, as I showed before. What I know is that I have never tinkered with something the existence of wich I didn't know. Thanks for your kindful help. (In reply to comment #7) > ~ $ eix -I bash > [I] app-shells/bash > Available versions: 3.1_p17 3.2_p39 ~3.2_p48 ~3.2_p48-r1 ~4.0_p10 > ~4.0_p10-r1 ~4.0_p17 ~4.0_p17-r1 ~4.0_p24 {afs bashlogger examples net nls > plugins vanilla} > Installed versions: 3.2_p39(17:21:03 08/04/09)(nls plugins -afs > -bashlogger -examples -vanilla) > Homepage: http://cnswww.cns.cwru.edu/~chet/bash/bashtop.html > Description: The standard GNU Bourne again shell > > ~ $ app-shells/bash-completion shouldn't be missing from that output, and therein lies the problem. If you install the bash-completion package all /should/ be well. It also explains why there wasn't a lot more output from your "grep '@(' /usr/share/bash-completion/*" call. Please report back your success or failure after installing app-shells/bash-completion. Thanks again for all the effort you're putting in with the extra info for this bug. So yeah, I can reproduce and fix this bug now. It just never occurred to me that people would choose to do that, so I missed it in the original report. My bad. Created attachment 199002 [details, diff] surfraw-fix_standalone_completion.patch Jeroen, The fix I've attached makes surfraw bash completion work correctly for people who do not wish to install the whole app-shells/bash-completion package for whatever reason. My suggestion for the echangelog message is: "Fixed completion script to work without app-shells/bash-completion installed, many thanks to urcindalo in Bug #277891." Thanks, James Well, that worked out quite well, I think. I must note that I wasn't previously aware of this Gentoo specific patch at all. It's in the tree now. Thanks everyone. > My suggestion for the echangelog message is: "Fixed completion script
> to work without app-shells/bash-completion installed, many thanks to
> urcindalo in Bug #277891."
I feel blushed. I did nothing to solve it. I just followed your directions.
By the way, I have bash-completion in my USE flags:
===
~ $ cat /etc/make.conf | grep bash
avahi bash-completion bcmath bdf beagle binary-drivers binfilter blas \
~ $ sudo euse -I bash-completion
global use flags (searching: bash-completion)
************************************************************
[+ C ] bash-completion - Enable bash-completion support
Installed packages matching this USE flag:
app-admin/eselect-1.1.1
app-portage/genlop-0.30.8-r2
app-text/tree-1.5.2.2
dev-util/git-1.6.3.3
dev-util/subversion-1.6.3
gnome-base/gvfs-1.0.3-r2
www-client/surfraw-2.2.5
local use flags (searching: bash-completion)
************************************************************
no matching entries found
~ $
===
Why, if I have this USE flag enabled, the bash-completion package is not installed as a dependency?
> ------- Comment #12 from urcindalo@gmail.com 2009-07-27 07:49 0000 ------- > By the way, I have bash-completion in my USE flags: <snip> > Why, if I have this USE flag enabled, the bash-completion package is not > installed as a dependency? Many packages don't explicitly require the app-shells/bash-completion package for their completion support, and this now includes surfraw. While it definitely provides additional functionality it shouldn't normally break systems when it isn't installed, you just found a case that hadn't been tested properly. I should add that it requires more user work to function without it but it does work, and if you've been using the completion from git and subversion without bash-completion installed you're obviously up to doing the configuration work yourself. If you've synced the portage tree since Saturday and re-emerge surfraw and you'll see it now works with or without app-shells/bash-completion installed when properly configured. Note that surfraw won't be automatically upgraded as it isn't a critical fix, just in case that wasn't clear. Finally, if you think app-shells/bash-completion should be installed automatically with USE=bash-completion my guess would be that it is a bug that needs to be filed separately with the maintainer of bash-completion.eclass, if there isn't one already of course. Thanks, James |