[Bash-completion-devel] [bash-completion-Bugs][314799] cd autocompletion fails when two folders share the first letters and contain spaces
bash-completion-Bugs item #314799 was changed at 2014-09-25 13:43 by Iñaki Baz Castillo You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314799group_id=100114 Status: Open Priority: 3 Submitted By: Iñaki Baz Castillo (ibc-guest) Assigned to: Nobody (None) Summary: cd autocompletion fails when two folders share the first letters and contain spaces Distribution: --Distribution-Agnostic-- Originally reported in: Debian BTS Milestone: None Status: None Original bug number: Initial Comment: - OS: OSX 10.9.4 - bash (installed with Homebrew): GNU bash, versión 4.3.18(1)-release (x86_64-apple-darwin13.3.0) - bash-completion2 (installed with Homebrew): 2.1 I do source the bash_completion file (brew --prefix points to /usr/local/ where the brew stuff is installed): source $(brew --prefix)/share/bash-completion/bash_completion Issue description: ~# mkdir qwe asd 1 ~# mkdir qwe asd 2 ~# cd qwe + TAB (press TAB multiple times) Nothing happens, it writes: cd qwe\ asd\ but nothing else, and in case you append 1 or 2, it does neither work. NOTE: ls command does work in the same scenario! NOTE: I attach a working patch (tested in my OSX) extracted from a bug report in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739835 -- Comment By: Iñaki Baz Castillo (ibc-guest) Date: 2014-09-25 13:43 Message: Thanks for the no-feedback guys. Great bug tracker anyway (where is the Send comment button?). -- Comment By: Iñaki Baz Castillo (ibc-guest) Date: 2014-09-03 19:56 Message: BTW, and I sorry for the comment, but this is the worst issue tracker I've ever seen. -- Comment By: Iñaki Baz Castillo (ibc-guest) Date: 2014-09-03 19:54 Message: NOTE: It seems that the issue affects bash 4.3 only. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314799group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314814] unexpected token `}'
bash-completion-Bugs item #314814 was changed at 2014-09-25 12:50 by Fred Olson You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314814group_id=100114 Status: Open Priority: 3 Submitted By: Fred Olson (fholson-guest) Assigned to: Nobody (None) Summary: unexpected token `}' Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Today after doing updates on my recently installed Ubuntu 14.04 system, when I open a terminal I get: bash: /usr/share/bash-completion/bash_completion: line 226: syntax error near unexpected token `}' bash: /usr/share/bash-completion/bash_completion: line 226: `}' So far I have not noticed any completion anomalies. Note tho I am not sure if it is relevant... prior to the install of Ubuntu 14.04, I have used used Ubuntu with the tcsh shell rather than bash (for historic reasons). I finally decided to convert to use bash. In tcsh I had accumulated numerous command aliases. I copied tcsh's .aliases file over to be the basis for my bash command aliases. I commented all aliases out and am gradually uncommenting and converting those I actually use now. Fred -- Fred H. Olson Minneapolis,MN 55411 USA(near north Mpls) Email:fholson at cohousing.org 612-588-9532 My Link Pg: http://fholson.cohousing.org My org: Communications for Justice -- Free, superior listserv's w/o ads -- Comment By: Fred Olson (fholson-guest) Date: 2014-09-25 12:50 Message: 9/25/14 i have now tracked down a way to avoid the bash-completion error messages. I had a command alias named done which displays a full screen DONE on the terminal to get my attention when a big file download is complete. If there is a bash alias named done or one named do the bash-completion error is shown. Should this problem be solved by alias being modified to prohibit aliases named do' or 'done' ? -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314814group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314814] unexpected token `}'
bash-completion-Bugs item #314814, was opened at 2014-09-13 11:28 by Fred Olson You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314814group_id=100114 Status: Open Priority: 3 Submitted By: Fred Olson (fholson-guest) Assigned to: Nobody (None) Summary: unexpected token `}' Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Today after doing updates on my recently installed Ubuntu 14.04 system, when I open a terminal I get: bash: /usr/share/bash-completion/bash_completion: line 226: syntax error near unexpected token `}' bash: /usr/share/bash-completion/bash_completion: line 226: `}' So far I have not noticed any completion anomalies. Note tho I am not sure if it is relevant... prior to the install of Ubuntu 14.04, I have used used Ubuntu with the tcsh shell rather than bash (for historic reasons). I finally decided to convert to use bash. In tcsh I had accumulated numerous command aliases. I copied tcsh's .aliases file over to be the basis for my bash command aliases. I commented all aliases out and am gradually uncommenting and converting those I actually use now. Fred -- Fred H. Olson Minneapolis,MN 55411 USA(near north Mpls) Email:fholson at cohousing.org 612-588-9532 My Link Pg: http://fholson.cohousing.org My org: Communications for Justice -- Free, superior listserv's w/o ads -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314814group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314799] cd autocompletion fails when two folders share the first letters and contain spaces
bash-completion-Bugs item #314799, was opened at 2014-09-03 19:51 by Iñaki Baz Castillo You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314799group_id=100114 Status: Open Priority: 3 Submitted By: Iñaki Baz Castillo (ibc-guest) Assigned to: Nobody (None) Summary: cd autocompletion fails when two folders share the first letters and contain spaces Distribution: --Distribution-Agnostic-- Originally reported in: Debian BTS Milestone: None Status: None Original bug number: Initial Comment: - OS: OSX 10.9.4 - bash (installed with Homebrew): GNU bash, versión 4.3.18(1)-release (x86_64-apple-darwin13.3.0) - bash-completion2 (installed with Homebrew): 2.1 I do source the bash_completion file (brew --prefix points to /usr/local/ where the brew stuff is installed): source $(brew --prefix)/share/bash-completion/bash_completion Issue description: ~# mkdir qwe asd 1 ~# mkdir qwe asd 2 ~# cd qwe + TAB (press TAB multiple times) Nothing happens, it writes: cd qwe\ asd\ but nothing else, and in case you append 1 or 2, it does neither work. NOTE: ls command does work in the same scenario! NOTE: I attach a working patch (tested in my OSX) extracted from a bug report in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739835 -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314799group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314799] cd autocompletion fails when two folders share the first letters and contain spaces
bash-completion-Bugs item #314799 was changed at 2014-09-03 19:54 by Iñaki Baz Castillo You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314799group_id=100114 Status: Open Priority: 3 Submitted By: Iñaki Baz Castillo (ibc-guest) Assigned to: Nobody (None) Summary: cd autocompletion fails when two folders share the first letters and contain spaces Distribution: --Distribution-Agnostic-- Originally reported in: Debian BTS Milestone: None Status: None Original bug number: Initial Comment: - OS: OSX 10.9.4 - bash (installed with Homebrew): GNU bash, versión 4.3.18(1)-release (x86_64-apple-darwin13.3.0) - bash-completion2 (installed with Homebrew): 2.1 I do source the bash_completion file (brew --prefix points to /usr/local/ where the brew stuff is installed): source $(brew --prefix)/share/bash-completion/bash_completion Issue description: ~# mkdir qwe asd 1 ~# mkdir qwe asd 2 ~# cd qwe + TAB (press TAB multiple times) Nothing happens, it writes: cd qwe\ asd\ but nothing else, and in case you append 1 or 2, it does neither work. NOTE: ls command does work in the same scenario! NOTE: I attach a working patch (tested in my OSX) extracted from a bug report in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739835 -- Comment By: Iñaki Baz Castillo (ibc-guest) Date: 2014-09-03 19:54 Message: NOTE: It seems that the issue affects bash 4.3 only. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314799group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314799] cd autocompletion fails when two folders share the first letters and contain spaces
bash-completion-Bugs item #314799 was changed at 2014-09-03 19:56 by Iñaki Baz Castillo You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314799group_id=100114 Status: Open Priority: 3 Submitted By: Iñaki Baz Castillo (ibc-guest) Assigned to: Nobody (None) Summary: cd autocompletion fails when two folders share the first letters and contain spaces Distribution: --Distribution-Agnostic-- Originally reported in: Debian BTS Milestone: None Status: None Original bug number: Initial Comment: - OS: OSX 10.9.4 - bash (installed with Homebrew): GNU bash, versión 4.3.18(1)-release (x86_64-apple-darwin13.3.0) - bash-completion2 (installed with Homebrew): 2.1 I do source the bash_completion file (brew --prefix points to /usr/local/ where the brew stuff is installed): source $(brew --prefix)/share/bash-completion/bash_completion Issue description: ~# mkdir qwe asd 1 ~# mkdir qwe asd 2 ~# cd qwe + TAB (press TAB multiple times) Nothing happens, it writes: cd qwe\ asd\ but nothing else, and in case you append 1 or 2, it does neither work. NOTE: ls command does work in the same scenario! NOTE: I attach a working patch (tested in my OSX) extracted from a bug report in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739835 -- Comment By: Iñaki Baz Castillo (ibc-guest) Date: 2014-09-03 19:56 Message: BTW, and I sorry for the comment, but this is the worst issue tracker I've ever seen. -- Comment By: Iñaki Baz Castillo (ibc-guest) Date: 2014-09-03 19:54 Message: NOTE: It seems that the issue affects bash 4.3 only. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314799group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314774] fusermount won't complete directories
bash-completion-Bugs item #314774, was opened at 2014-07-29 18:21 by Adam Nielsen You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314774group_id=100114 Status: Open Priority: 3 Submitted By: Adam Nielsen (malvineous-guest) Assigned to: Nobody (None) Summary: fusermount won't complete directories Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: If you use FUSE to mount a directory, you can't unmount it by giving the directory name: $ mkdir test1234567890 $ fusermount -u testtab Even when test1234567890 is actually mounted (via fstab or not) it won't autocomplete. I believe the completion needs to change so that either it will autocomplete directory names, or it will autocomplete any path that is an active mountpoint (e.g. listed in /etc/mtab) -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314774group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314770] should offer .dbk for xsltproc
bash-completion-Bugs item #314770 was changed at 2014-07-19 17:16 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314770group_id=100114 Status: Closed Priority: 3 Submitted By: victory .deb (victory-guest) Assigned to: Nobody (None) Summary: should offer .dbk for xsltproc Distribution: Debian Originally reported in: None Milestone: None Status: Fix Committed Original bug number: Initial Comment: currently it does not offer .dbk (docbook xml) file despite it is often used for debian docs. before: victory@debian:/.../apt$ xsltproc .../docbook.xsl doc/ja/[TAB][TAB] apt-cache.ja.8.xml apt-secure.ja.8.xml apt-cdrom.ja.8.xml apt-sortpkgs.ja.1.xml apt-config.ja.8.xmlapt.conf.ja.5.xml apt-extracttemplates.ja.1.xml apt.ja.8.xml apt-ftparchive.ja.1.xmlapt_preferences.ja.5.xml apt-get.ja.8.xml manpage-style.xsl apt-key.ja.8.xml sources.list.ja.5.xml apt-mark.ja.8.xml after patch applied: victory@debian:/.../apt$ xsltproc .../docbook.xsl doc/ja/[TAB][TAB] apt-cache.ja.8.xml apt-sortpkgs.ja.1.xml apt-cdrom.ja.8.xml apt.conf.ja.5.xml apt-config.ja.8.xmlapt.ja.8.xml apt-extracttemplates.ja.1.xml apt_preferences.ja.5.xml apt-ftparchive.ja.1.xmlguide.ja.dbk apt-get.ja.8.xml manpage-style.xsl apt-key.ja.8.xml offline.ja.dbk apt-mark.ja.8.xml sources.list.ja.5.xml apt-secure.ja.8.xml -- Comment By: Ville Skyttä (scop-guest) Date: 2014-07-19 17:16 Message: http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=ab8eeb3a713b1223752336fc4cb0d515c24579cc -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314770group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314533] SSH Completion Failed
bash-completion-Bugs item #314533 was changed at 2014-07-19 20:04 by Ville
Skyttä
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114
Status: Open
Priority: 3
Submitted By: Neville Gao (figod-guest)
Assigned to: Nobody (None)
Summary: SSH Completion Failed
Distribution: Debian
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
Following message[1] appears when I type 'ssh TAB' every time. I attached my
.ssh/config and proposal patch.
[1] sed: -e expression #1, char 97: invalid reference \2 on `s' command's RHS
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-07-19 20:04
Message:
I don't have access to such a box.
--
Comment By: Neville Gao (figod-guest)
Date: 2014-07-18 09:33
Message:
I tested on a fresh Debian7, can you please try this?
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-07-12 15:38
Message:
I'm using sed 4.2.2 as well (on Fedora 20), and running the same command on
shell produces no output. It doesn't do anything either because ${config[@]} is
empty, but replacing it with ~/.ssh/config produces the expected output and no
errors. Even adding --posix to sed options doesn't cause any problems here.
--
Comment By: Neville Gao (figod-guest)
Date: 2014-06-25 08:38
Message:
I'm using sed 4.2.2
I ran the following single command from bash:
sed -ne 's/^[ \t]*[Hh][Oo][Ss][Tt]\([Nn][Aa][Mm][Ee]\)\{0,1\}['$'\t
'']\{1,\}\([^#*?]*\)\(#.*\)\{0,1\}$/\2/p' ${config[@]}
It said the errors.
--
Comment By: Ville Skyttä (scop-guest)
Date: 2013-12-07 00:05
Message:
I cannot reproduce, I get no errors when I complete with your config, so more
details are needed.
Looking at the patch, I'm confused; are you sure you got it the right way?
Turning \{0,1\} into ? and \{1,\} into + is introducing a sed portability
issue, and removing the backslash from front of ( and ) actually *introduces*
the invalid reference \2 errors you're seeing as the unescaped parenthesis
are no longer capturing groups...?
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314533] SSH Completion Failed
bash-completion-Bugs item #314533 was changed at 2014-07-18 14:33 by Neville Gao
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114
Status: Open
Priority: 3
Submitted By: Neville Gao (figod-guest)
Assigned to: Nobody (None)
Summary: SSH Completion Failed
Distribution: Debian
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
Following message[1] appears when I type 'ssh TAB' every time. I attached my
.ssh/config and proposal patch.
[1] sed: -e expression #1, char 97: invalid reference \2 on `s' command's RHS
--
Comment By: Neville Gao (figod-guest)
Date: 2014-07-18 14:33
Message:
I tested on a fresh Debian7, can you please try this?
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-07-12 20:38
Message:
I'm using sed 4.2.2 as well (on Fedora 20), and running the same command on
shell produces no output. It doesn't do anything either because ${config[@]} is
empty, but replacing it with ~/.ssh/config produces the expected output and no
errors. Even adding --posix to sed options doesn't cause any problems here.
--
Comment By: Neville Gao (figod-guest)
Date: 2014-06-25 13:38
Message:
I'm using sed 4.2.2
I ran the following single command from bash:
sed -ne 's/^[ \t]*[Hh][Oo][Ss][Tt]\([Nn][Aa][Mm][Ee]\)\{0,1\}['$'\t
'']\{1,\}\([^#*?]*\)\(#.*\)\{0,1\}$/\2/p' ${config[@]}
It said the errors.
--
Comment By: Ville Skyttä (scop-guest)
Date: 2013-12-07 06:05
Message:
I cannot reproduce, I get no errors when I complete with your config, so more
details are needed.
Looking at the patch, I'm confused; are you sure you got it the right way?
Turning \{0,1\} into ? and \{1,\} into + is introducing a sed portability
issue, and removing the backslash from front of ( and ) actually *introduces*
the invalid reference \2 errors you're seeing as the unescaped parenthesis
are no longer capturing groups...?
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314770] should offer .dbk for xsltproc
bash-completion-Bugs item #314770, was opened at 2014-07-19 02:04 by victory .deb You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314770group_id=100114 Status: Open Priority: 3 Submitted By: victory .deb (victory-guest) Assigned to: Nobody (None) Summary: should offer .dbk for xsltproc Distribution: Debian Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: currently it does not offer .dbk (docbook xml) file despite it is often used for debian docs. before: victory@debian:/.../apt$ xsltproc .../docbook.xsl doc/ja/[TAB][TAB] apt-cache.ja.8.xml apt-secure.ja.8.xml apt-cdrom.ja.8.xml apt-sortpkgs.ja.1.xml apt-config.ja.8.xmlapt.conf.ja.5.xml apt-extracttemplates.ja.1.xml apt.ja.8.xml apt-ftparchive.ja.1.xmlapt_preferences.ja.5.xml apt-get.ja.8.xml manpage-style.xsl apt-key.ja.8.xml sources.list.ja.5.xml apt-mark.ja.8.xml after patch applied: victory@debian:/.../apt$ xsltproc .../docbook.xsl doc/ja/[TAB][TAB] apt-cache.ja.8.xml apt-sortpkgs.ja.1.xml apt-cdrom.ja.8.xml apt.conf.ja.5.xml apt-config.ja.8.xmlapt.ja.8.xml apt-extracttemplates.ja.1.xml apt_preferences.ja.5.xml apt-ftparchive.ja.1.xmlguide.ja.dbk apt-get.ja.8.xml manpage-style.xsl apt-key.ja.8.xml offline.ja.dbk apt-mark.ja.8.xml sources.list.ja.5.xml apt-secure.ja.8.xml -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314770group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314533] SSH Completion Failed
bash-completion-Bugs item #314533 was changed at 2014-07-12 15:38 by Ville
Skyttä
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114
Status: Open
Priority: 3
Submitted By: Neville Gao (figod-guest)
Assigned to: Nobody (None)
Summary: SSH Completion Failed
Distribution: Debian
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
Following message[1] appears when I type 'ssh TAB' every time. I attached my
.ssh/config and proposal patch.
[1] sed: -e expression #1, char 97: invalid reference \2 on `s' command's RHS
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-07-12 15:38
Message:
I'm using sed 4.2.2 as well (on Fedora 20), and running the same command on
shell produces no output. It doesn't do anything either because ${config[@]} is
empty, but replacing it with ~/.ssh/config produces the expected output and no
errors. Even adding --posix to sed options doesn't cause any problems here.
--
Comment By: Neville Gao (figod-guest)
Date: 2014-06-25 08:38
Message:
I'm using sed 4.2.2
I ran the following single command from bash:
sed -ne 's/^[ \t]*[Hh][Oo][Ss][Tt]\([Nn][Aa][Mm][Ee]\)\{0,1\}['$'\t
'']\{1,\}\([^#*?]*\)\(#.*\)\{0,1\}$/\2/p' ${config[@]}
It said the errors.
--
Comment By: Ville Skyttä (scop-guest)
Date: 2013-12-07 00:05
Message:
I cannot reproduce, I get no errors when I complete with your config, so more
details are needed.
Looking at the patch, I'm confused; are you sure you got it the right way?
Turning \{0,1\} into ? and \{1,\} into + is introducing a sed portability
issue, and removing the backslash from front of ( and ) actually *introduces*
the invalid reference \2 errors you're seeing as the unescaped parenthesis
are no longer capturing groups...?
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314720] set -o posix in test/config/bashrc breaks bash-valid code.
bash-completion-Bugs item #314720 was changed at 2014-07-01 22:25 by Ville
Skyttä
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314720group_id=100114
Status: Closed
Priority: 3
Submitted By: Dams Nadé (anvil-guest)
Assigned to: Nobody (None)
Summary: set -o posix in test/config/bashrc breaks bash-valid code.
Distribution: None
Originally reported in: None
Milestone: None
Status: Fix Committed
Original bug number:
Initial Comment:
#314716, I've submitted a function with a () construction. While this is valid
bash syntax, it cannot be parsed by bash if posix mode is enabled.
I would say set -o posix plays against the Use the full power of bash =
4.1 statement from the README file, CONTRIBUTING section.
Since a lot of bash completion code is not POSIX compliant ([[, arrays,
extglob, etc), I would suggest *disabling* posix mode in the test suite
bashrc configuration file.
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-07-01 22:25
Message:
While the posix mode has this and possibly some limitations that make the shell
less powerful, I think it is mostly a behavioral setting just like failglob,
and we want bash-completion to work no matter if it's enabled or not.
For the (...) case, we already have a handled case in-tree, see grep -A 4
posix completions/make
I've applied the second patch (with commit message improvements) as well as
made _save_env save the state of shell variables.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-14 18:47
Message:
So here are 2 trivial patches. One to disable posix in test/config/bashr, the
other to make the _save_env function result posix-independant.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-14 01:02
Message:
Disabling posix in test/config/bashrc actually breaks the test suite, but I
think I've found the issue.
When posix is enabled, the set command (without any parameter) only shows
variables, but when posix is disabled the same set command will also print
functions definitions (with full functions body).
So depending of the posix option setting, the _save_env function in
test/lib/library.exp will not dump the same things. So the function should be
instead :
proc _save_env {{file }} {
assert_bash_exec { (set -o posix ; set); declare -F; shopt -p; }
\$file\
}
I think it's okay to do this, because it's not about posix itself, it's more
about the content we want to compare.
( And maybe the _save_env should also dump set -o output, so that we know
bash_completion does not change bash behaviour )
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314720group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314720] set -o posix in test/config/bashrc breaks bash-valid code.
bash-completion-Bugs item #314720 was changed at 01/07/2014 22:57 by Dams Nadé
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314720group_id=100114
Status: Closed
Priority: 3
Submitted By: Dams Nadé (anvil-guest)
Assigned to: Nobody (None)
Summary: set -o posix in test/config/bashrc breaks bash-valid code.
Distribution: None
Originally reported in: None
Milestone: None
Status: Fix Committed
Original bug number:
Initial Comment:
#314716, I've submitted a function with a () construction. While this is valid
bash syntax, it cannot be parsed by bash if posix mode is enabled.
I would say set -o posix plays against the Use the full power of bash =
4.1 statement from the README file, CONTRIBUTING section.
Since a lot of bash completion code is not POSIX compliant ([[, arrays,
extglob, etc), I would suggest *disabling* posix mode in the test suite
bashrc configuration file.
--
Comment By: Dams Nadé (anvil-guest)
Date: 01/07/2014 22:57
Message:
posix is not something you want to enforce.
Not only [[, arrays, local variables, extglob (which bash-completion enforces),
printf -v, (( )) and many other constructions are definitely not posix but also
it would be *impossible* to create a posix bash completion implementation. You
could say that bash-completion breaks posixness on an almost-every-line basis.
Plus in posix mode, bash refuses to parse the () substitution at all. While
not currently used in bash-completion, I've submitted a few patch containing
some of them. Try to work around these would bloat the code a bit more.
So it would perfectly make sense to disable posix in bash completion test
suite, imho.
---
And for the record about failglob,
* if it works with failglob it will work without
* if it fails with failglob, then it will also fail at some point when
failglob is disabled.
Failglob only points at insecure patterns.
So methinks failglob should be kept in mind at all time and never be disabled
for the purpose of testing and validating bash-completion code robustness.
And by the way, applying all of my patches (attached to bug reports i've
opened) fixes (iirc) all failglob issues detected by the test suite.
--
Comment By: Ville Skyttä (scop-guest)
Date: 01/07/2014 21:25
Message:
While the posix mode has this and possibly some limitations that make the shell
less powerful, I think it is mostly a behavioral setting just like failglob,
and we want bash-completion to work no matter if it's enabled or not.
For the (...) case, we already have a handled case in-tree, see grep -A 4
posix completions/make
I've applied the second patch (with commit message improvements) as well as
made _save_env save the state of shell variables.
--
Comment By: Dams Nadé (anvil-guest)
Date: 14/06/2014 17:47
Message:
So here are 2 trivial patches. One to disable posix in test/config/bashr, the
other to make the _save_env function result posix-independant.
--
Comment By: Dams Nadé (anvil-guest)
Date: 14/06/2014 00:02
Message:
Disabling posix in test/config/bashrc actually breaks the test suite, but I
think I've found the issue.
When posix is enabled, the set command (without any parameter) only shows
variables, but when posix is disabled the same set command will also print
functions definitions (with full functions body).
So depending of the posix option setting, the _save_env function in
test/lib/library.exp will not dump the same things. So the function should be
instead :
proc _save_env {{file }} {
assert_bash_exec { (set -o posix ; set); declare -F; shopt -p; }
\$file\
}
I think it's okay to do this, because it's not about posix itself, it's more
about the content we want to compare.
( And maybe the _save_env should also dump set -o output, so that we know
bash_completion does not change bash behaviour )
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314720group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314720] set -o posix in test/config/bashrc breaks bash-valid code.
bash-completion-Bugs item #314720 was changed at 2014-07-02 00:05 by Ville
Skyttä
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314720group_id=100114
Status: Closed
Priority: 3
Submitted By: Dams Nadé (anvil-guest)
Assigned to: Nobody (None)
Summary: set -o posix in test/config/bashrc breaks bash-valid code.
Distribution: None
Originally reported in: None
Milestone: None
Status: Fix Committed
Original bug number:
Initial Comment:
#314716, I've submitted a function with a () construction. While this is valid
bash syntax, it cannot be parsed by bash if posix mode is enabled.
I would say set -o posix plays against the Use the full power of bash =
4.1 statement from the README file, CONTRIBUTING section.
Since a lot of bash completion code is not POSIX compliant ([[, arrays,
extglob, etc), I would suggest *disabling* posix mode in the test suite
bashrc configuration file.
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-07-02 00:05
Message:
You seem to be misunderstanding what posix mode is. It does not strip bash
down from all of its additional features to a plain POSIX sh, instead per the
man page: Change the behavior of bash where the default operation differs
from the POSIX standard to match the standard (posix mode).
Just try out bash completion after set -o posix. Appears to work just fine
for me.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-07-01 23:57
Message:
posix is not something you want to enforce.
Not only [[, arrays, local variables, extglob (which bash-completion enforces),
printf -v, (( )) and many other constructions are definitely not posix but also
it would be *impossible* to create a posix bash completion implementation. You
could say that bash-completion breaks posixness on an almost-every-line basis.
Plus in posix mode, bash refuses to parse the () substitution at all. While
not currently used in bash-completion, I've submitted a few patch containing
some of them. Try to work around these would bloat the code a bit more.
So it would perfectly make sense to disable posix in bash completion test
suite, imho.
---
And for the record about failglob,
* if it works with failglob it will work without
* if it fails with failglob, then it will also fail at some point when
failglob is disabled.
Failglob only points at insecure patterns.
So methinks failglob should be kept in mind at all time and never be disabled
for the purpose of testing and validating bash-completion code robustness.
And by the way, applying all of my patches (attached to bug reports i've
opened) fixes (iirc) all failglob issues detected by the test suite.
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-07-01 22:25
Message:
While the posix mode has this and possibly some limitations that make the shell
less powerful, I think it is mostly a behavioral setting just like failglob,
and we want bash-completion to work no matter if it's enabled or not.
For the (...) case, we already have a handled case in-tree, see grep -A 4
posix completions/make
I've applied the second patch (with commit message improvements) as well as
made _save_env save the state of shell variables.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-14 18:47
Message:
So here are 2 trivial patches. One to disable posix in test/config/bashr, the
other to make the _save_env function result posix-independant.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-14 01:02
Message:
Disabling posix in test/config/bashrc actually breaks the test suite, but I
think I've found the issue.
When posix is enabled, the set command (without any parameter) only shows
variables, but when posix is disabled the same set command will also print
functions definitions (with full functions body).
So depending of the posix option setting, the _save_env function in
test/lib/library.exp will not dump the same things. So the function should be
instead :
proc _save_env {{file }} {
assert_bash_exec { (set -o posix ; set); declare -F; shopt -p; }
\$file\
}
I think it's okay to do this, because it's not about posix itself, it's more
about the content we want to compare.
( And maybe the _save_env should also dump set -o output, so that we know
bash_completion does not change bash behaviour )
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314720group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http
[Bash-completion-devel] [bash-completion-Bugs][314533] SSH Completion Failed
bash-completion-Bugs item #314533 was changed at 2014-06-25 13:38 by Neville Gao
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114
Status: Open
Priority: 3
Submitted By: Neville Gao (figod-guest)
Assigned to: Nobody (None)
Summary: SSH Completion Failed
Distribution: Debian
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
Following message[1] appears when I type 'ssh TAB' every time. I attached my
.ssh/config and proposal patch.
[1] sed: -e expression #1, char 97: invalid reference \2 on `s' command's RHS
--
Comment By: Neville Gao (figod-guest)
Date: 2014-06-25 13:38
Message:
I'm using sed 4.2.2
I ran the following single command from bash:
sed -ne 's/^[ \t]*[Hh][Oo][Ss][Tt]\([Nn][Aa][Mm][Ee]\)\{0,1\}['$'\t
'']\{1,\}\([^#*?]*\)\(#.*\)\{0,1\}$/\2/p' ${config[@]}
It said the errors.
--
Comment By: Ville Skyttä (scop-guest)
Date: 2013-12-07 06:05
Message:
I cannot reproduce, I get no errors when I complete with your config, so more
details are needed.
Looking at the patch, I'm confused; are you sure you got it the right way?
Turning \{0,1\} into ? and \{1,\} into + is introducing a sed portability
issue, and removing the backslash from front of ( and ) actually *introduces*
the invalid reference \2 errors you're seeing as the unescaped parenthesis
are no longer capturing groups...?
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314735] ant completion ignores $ANT_ARGS
bash-completion-Bugs item #314735, was opened at 2014-06-17 11:12 by Christian Schmidt You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314735group_id=100114 Status: Open Priority: 3 Submitted By: Christian Schmidt (c960657-guest) Assigned to: Nobody (None) Summary: ant completion ignores $ANT_ARGS Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: In my .bashrc I have defined the following environment variable: export ANT_ARGS=-find build.xml This allows me to run ant foo-target in any subfolder of my project. However, the ant completion only suggests the possible targets when I am in the folder containing build.xml. The completion script should support the -find command line argument in addition to -buildfile. Also, it should not only look for -find/-buildfile in arguments previously typed on the command line but also in the $ANT_ARGS environment variable. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314735group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314720] set -o posix in test/config/bashrc breaks bash-valid code.
bash-completion-Bugs item #314720 was changed at 14/06/2014 17:47 by Dams Nadé
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314720group_id=100114
Status: Open
Priority: 3
Submitted By: Dams Nadé (anvil-guest)
Assigned to: Nobody (None)
Summary: set -o posix in test/config/bashrc breaks bash-valid code.
Distribution: None
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
#314716, I've submitted a function with a () construction. While this is valid
bash syntax, it cannot be parsed by bash if posix mode is enabled.
I would say set -o posix plays against the Use the full power of bash =
4.1 statement from the README file, CONTRIBUTING section.
Since a lot of bash completion code is not POSIX compliant ([[, arrays,
extglob, etc), I would suggest *disabling* posix mode in the test suite
bashrc configuration file.
--
Comment By: Dams Nadé (anvil-guest)
Date: 14/06/2014 17:47
Message:
So here are 2 trivial patches. One to disable posix in test/config/bashr, the
other to make the _save_env function result posix-independant.
--
Comment By: Dams Nadé (anvil-guest)
Date: 14/06/2014 00:02
Message:
Disabling posix in test/config/bashrc actually breaks the test suite, but I
think I've found the issue.
When posix is enabled, the set command (without any parameter) only shows
variables, but when posix is disabled the same set command will also print
functions definitions (with full functions body).
So depending of the posix option setting, the _save_env function in
test/lib/library.exp will not dump the same things. So the function should be
instead :
proc _save_env {{file }} {
assert_bash_exec { (set -o posix ; set); declare -F; shopt -p; }
\$file\
}
I think it's okay to do this, because it's not about posix itself, it's more
about the content we want to compare.
( And maybe the _save_env should also dump set -o output, so that we know
bash_completion does not change bash behaviour )
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314720group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][313855] completion for loadkeys
bash-completion-Bugs item #313855 was changed at 14/06/2014 22:36 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=313855group_id=100114 Status: Open Priority: 1 Submitted By: Andre Schmidt (oskude-guest) Assigned to: Nobody (None) Summary: completion for loadkeys Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: thought it would be nice if upstream had this :D -- Comment By: Dams Nadé (anvil-guest) Date: 14/06/2014 22:36 Message: FTR https://lists.alioth.debian.org/pipermail/bash-completion-devel/2014-June/005446.html -- Comment By: Igor Murzov (garik-guest) Date: 13/10/2012 17:40 Message: This completion needs some love. Coding style should be fixed. You can learn it by example from other scripts. Also try to avoid using find as it is not portable. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=313855group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314725] nullglob does not work when failglob is enabled
bash-completion-Bugs item #314725, was opened at 12/06/2014 21:49 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314725group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: nullglob does not work when failglob is enabled Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: The _services and _xinetd_services are a bit broken when failglob is enabled. 1. failglob has actually a bigger priority than nullglob, so failglob prevents nullglob to happen. We should disable and restore failglob when enabling/restoring nullglob. and 2. the printf statements in the array assignements create another step of glob + word splitting to happen, they should be removed. See attached patches. They should prevent chkconfig completion from failing under some circumstances, like when no xinetd services are installed. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314725group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314726] _parse_help result makes java completion fail with failglob.
bash-completion-Bugs item #314726, was opened at 12/06/2014 23:18 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314726group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: _parse_help result makes java completion fail with failglob. Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: java -help has a funny line : -? -help print this help message This is due to the way the $(_parse_help) expansion result is assigned to the COMPREPLY array. The expression array=( $(command expansion) ) makes the result the expansion being re-word-splitted and re-globbed. While that kind of expansion is *everywhere* in the bash completion, I've currently only found a problem in the java completion. arrays should be assigned from expansion either by using combinations of loops and read -a (command expansion), or mapfile -t (command expansion) e.g : the java case can be fixed by doing : mapfile -t COMPREPLY ( compgen -W '$( _parse_help $1 -help )' -- $cur ) See attached patch. Be careful with this patch though, because it will make the test suite break. See [#314720] for more details about that. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314726group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314703] README says to run included configure script, but none is included
bash-completion-Bugs item #314703 was changed at 2014-06-12 21:35 by Ian Kelling You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314703group_id=100114 Status: Closed Priority: 3 Submitted By: Ian Kelling (iankelling-guest) Assigned to: Nobody (None) Summary: README says to run included configure script, but none is included Distribution: None Originally reported in: None Milestone: None Status: Invalid Original bug number: Initial Comment: No configure script is included, yet the README file states: If you don't have the package readily available for your distribution, or you simply don't want to use one, you can install bash completion using the standard commands for GNU autotools packages: ./configure make make check # optional, requires dejagnu and tcllib make install # as root -- Comment By: Ian Kelling (iankelling-guest) Date: 2014-06-12 21:35 Message: Thanks Ville, good answer. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-03 11:34 Message: There's some discussion about this on the mailing list today. But anyway, bootstrapping an autotools project usually starts with for example running autoreconf -i. You'll probably need a bunch of packages installed (automake, autoconf, etc etc). I'm not going to even try to write a autotools tutorial here or elsewhere, autoreconf should tell you what you're missing, if anything. Another alternative to autotools stuff, especially if you're just testing a git snapshot for yourself, is just to use it, no need to bother with installing it. For example I have my git clone in my ~/cvs/bash-completion dir, and this in my ~/.bashrc: [[ $PS1 !$BASH_COMPLETION_COMPAT_DIR ]] \ . ~/cvs/bash-completion/bash_completion On the other hand we do set up a bunch of symlinks in the completions dir during make which requires an autotools-bootstrapped (and configured) dir, so at least that part of the setup will be incomplete if you don't do it. But it's good enough to test many things. If someone wants to submit a patch to let's say README based on this discussion, feel free. -- Comment By: Ian! D. Allen (idallen-guest) Date: 2014-06-02 17:08 Message: Please tell me or point me at documentation on how to install and test the current snapshot, if following the README won't work. I don't speak git much yet, but I see that I can get a lovely tarball snapshot, that I can't install and use because the included documentation is wrong for that kind of tarball. Perhaps you could create a README_GIT_SNAPSHOT to help those of us who are trying to help you test the software? -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-01 12:38 Message: README documents setup from release tarball, the script is included in it and intentionally not in git. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314703group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314713] man completion is not failglob complaint
bash-completion-Bugs item #314713 was changed at 11/06/2014 13:17 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314713group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: man completion is not failglob complaint Distribution: None Originally reported in: None Milestone: 2.0 Status: Accepted Original bug number: Initial Comment: The man completion is not failglob compliant because it relies on way too much on glob patterns stored in parameters (which is not meant to be used that way). The attached patch propose ls-free nullglob-based more robust implementation. -- Comment By: Dams Nadé (anvil-guest) Date: 11/06/2014 13:17 Message: (here's the fixed patch, sorry for the noise) -- Comment By: Dams Nadé (anvil-guest) Date: 10/06/2014 19:21 Message: Hm, be careful, the last change of the patch is bad. $mansect should not be quoted. It's a pattern, and meant to be used unquoted inside [[ ]]. Sorry about that. -- Comment By: Igor Murzov (garik-guest) Date: 10/06/2014 00:23 Message: I can confirm that the patch fixes test failures for me :) -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314713group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314716] LVM completion fixes and enhancements (failglob, sizes...)
bash-completion-Bugs item #314716 was changed at 11/06/2014 20:06 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314716group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: LVM completion fixes and enhancements (failglob, sizes...) Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Please find attached 3 patches for LVM : * 0001-lvm-_lvm_count_args-parameter-must-be-quoted-in-orde.patch : In completions/lvm, the _lvm_count_args functions takes a pattern as parameter. In the rest of the file, the given parameter is not correctly quoted. * 0002-lvm-_lvm-using-a-single-pattern-case-and-invoking-fu.patch A purely esthetic change, which shortens the 'case' statement in _lvm. * 0003-lvm-_lvm_sizes-new-implementation-able-to-handle-rel.patch A new implementation for _lvm_sizes. This should fix the relative-size completion issue described in [#311391]. -- Comment By: Dams Nadé (anvil-guest) Date: 11/06/2014 20:06 Message: Let me explain the patches a bit, then, just so that the reader can understand a bit more. 0005-lvm-dynamically-compute-the-available-field-names-fo.patch The -o option of lvs, pvs and vgs commands acts like 'ps -o field1,field2'. The bash completion currently only propose a reduced and hardcoded list of field names. The complete field names list can be seen in if you run any of those 3 commands with -o any_bogus_field_name. The _lvpvvgs_fields function parses this output, and fill 3 variables (lvs_fields, pvs_fields and vgs_fields), which are simply reused right after by the completion functions. That way, the lists does not have to be manually maintained. 0004-lvm-using-vgs-pvs-lvs-in-_lvm_volumegroups-_lvm_phys.patch The _lvm_volumegroups function currently in bash completion uses vgscan and parses its output with a sed. As explained right above, the vgs command be used to obtained any information about volume groups by simply specifying the fields we want with the -o option. e.g The vgscan | sed, would grab the Found volume group line and print fedora. [anvil@tartine ~/git/bash-completion]# sudo vgscan Reading all physical volumes. This may take a while... Found volume group fedora using metadata type lvm2 You can just print the volume groups names by using vgs. [anvil@tartine ~/git/bash-completion]# sudo vgs -o vg_name VG fedora The --noheadings option just remove the upper line containing fields names. The same way, we can use lvs and pvs to obtain logical and physical volumes names. 0003-lvm-_lvm_sizes-new-implementation-able-to-handle-rel.patch The _lvm_sizes function currently only proposes units single letters, which is a kinda useless (and buggy, it seems according to #311391). The new function can construct a number. Since some LVM binaries (lvextend, ...) accept relative numbers, the new function can also construct this kind of numbers, when given proper parameters. -- Comment By: Ville Skyttä (scop-guest) Date: 07/06/2014 11:35 Message: 0001 and 0002 (with slight modifications) applied, hopefully someone who actually uses lvm will take a look at the rest. -- Comment By: Dams Nadé (anvil-guest) Date: 07/06/2014 00:41 Message: 0005-lvm-dynamically-compute-the-available-field-names-fo.patch : The currently provided list of field names for pvs/lvs/vgs is incomplete. I suggest parsing these commands stderr to compute the full list of available fields, thus enhancing the completion. -- Comment By: Dams Nadé (anvil-guest) Date: 06/06/2014 23:49 Message: * 0004-lvm-using-vgs-pvs-lvs-in-_lvm_volumegroups-_lvm_phys.patch We can remove the use of sed in the functions providing pv/vg/lv names by using pvs/vgs/lvs instead of pvscan/vgscan/lvscan. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314716group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314722] Add test/site.exp and test/site.bak to .gitignore
bash-completion-Bugs item #314722 was changed at 2014-06-12 02:05 by Igor Murzov You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314722group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: Add test/site.exp and test/site.bak to .gitignore Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: 2.0 Status: Fix Committed Original bug number: Initial Comment: Those 2 files are not supposed to be followed by git and they should be ignored. See proposed patch. -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-12 02:05 Message: Applied with a minor modification: https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-completion/bash-completion.git;a=commit;h=afe39fd1e171d0ea3d4fb8ec0d8c8c14fa120ed8 Thanks. -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-11 10:04 Message: FTR, here's the content en site.exp : ## these variables are automatically generated by make ## # Do not edit here. If you wish to override these values # edit the last section set srcdir . set objdir /home/anvil/git/bash-completion/test ## End of auto-generated content; you can edit from here. ## The site.bak is a backup when the file gets overridden -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-11 10:01 Message: They get created during the make check process if I'm not mistaken. -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-11 03:06 Message: Where did you get these two files? I can't seems to find anything related. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314722group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314709] -? triggers failglob if left unquoted
bash-completion-Bugs item #314709 was changed at 10/06/2014 08:24 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: -? triggers failglob if left unquoted Distribution: None Originally reported in: None Milestone: 2.0 Status: Fix Committed Original bug number: Initial Comment: Since '?' is a glob char, it needs to be quoted or an error will be triggered when using failglob. The ssh-add/ssh-keygen completions are broken due to this issue. See attached trivial patch. -- Comment By: Dams Nadé (anvil-guest) Date: 10/06/2014 08:24 Message: If, this is not the way it should be fixed, IMHO. If it still fails, then the problem is in _parse_help. -- Comment By: Igor Murzov (garik-guest) Date: 10/06/2014 00:52 Message: I fixed the issue for me with https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-completion/bash-completion.git;a=commit;h=60b8fabec499dbd56636548369ff3796e0d0d0fd -- Comment By: Igor Murzov (garik-guest) Date: 09/06/2014 23:33 Message: The issue doesn't seem fixed for me. -- Comment By: Ville Skyttä (scop-guest) Date: 03/06/2014 22:15 Message: Applied, thanks -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314722] Add test/site.exp and test/site.bak to .gitignore
bash-completion-Bugs item #314722, was opened at 10/06/2014 13:14 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314722group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: Add test/site.exp and test/site.bak to .gitignore Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: 2.0 Status: None Original bug number: Initial Comment: Those 2 files are not supposed to be followed by git and they should be ignored. See proposed patch. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314722group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314709] -? triggers failglob if left unquoted
bash-completion-Bugs item #314709 was changed at 2014-06-10 17:09 by Igor Murzov You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: -? triggers failglob if left unquoted Distribution: None Originally reported in: None Milestone: 2.0 Status: Fix Committed Original bug number: Initial Comment: Since '?' is a glob char, it needs to be quoted or an error will be triggered when using failglob. The ssh-add/ssh-keygen completions are broken due to this issue. See attached trivial patch. -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-10 17:09 Message: I have tried to fix the issue this way. But some completions pass multiple words as a help parameter. See completions/valgrind for example. -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-10 10:29 Message: Please consider reverting your change and applying this patch instead. -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-10 10:24 Message: If, this is not the way it should be fixed, IMHO. If it still fails, then the problem is in _parse_help. -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-10 02:52 Message: I fixed the issue for me with https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-completion/bash-completion.git;a=commit;h=60b8fabec499dbd56636548369ff3796e0d0d0fd -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-10 01:33 Message: The issue doesn't seem fixed for me. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-04 00:15 Message: Applied, thanks -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314709] -? triggers failglob if left unquoted
bash-completion-Bugs item #314709 was changed at 10/06/2014 15:17 by Dams Nadé
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114
Status: Closed
Priority: 3
Submitted By: Dams Nadé (anvil-guest)
Assigned to: Nobody (None)
Summary: -? triggers failglob if left unquoted
Distribution: None
Originally reported in: None
Milestone: 2.0
Status: Fix Committed
Original bug number:
Initial Comment:
Since '?' is a glob char, it needs to be quoted or an error will be triggered
when using failglob.
The ssh-add/ssh-keygen completions are broken due to this issue.
See attached trivial patch.
--
Comment By: Dams Nadé (anvil-guest)
Date: 10/06/2014 15:17
Message:
Hm, let's change the _parse_help signature, then ?
What about in _parse_help something like :
_parse_help()
{
eval local cmd=$( quote $1 )
local line
shift
local -a help_params
if [[ $# -ge 1 ]]
then
help_params=($@)
else
help_params=(--help)
fi
{ case $cmd in
-) cat ;;
*) LC_ALL=C $( dequote $cmd ) ${help_params[@]} 21 ;;
esac }
I really think relying on word-spliting is a bad bad thing
--
Comment By: Igor Murzov (garik-guest)
Date: 10/06/2014 15:09
Message:
I have tried to fix the issue this way. But some completions pass multiple
words as a help parameter. See completions/valgrind for example.
--
Comment By: Dams Nadé (anvil-guest)
Date: 10/06/2014 08:29
Message:
Please consider reverting your change and applying this patch instead.
--
Comment By: Dams Nadé (anvil-guest)
Date: 10/06/2014 08:24
Message:
If, this is not the way it should be fixed, IMHO. If it still fails, then the
problem is in _parse_help.
--
Comment By: Igor Murzov (garik-guest)
Date: 10/06/2014 00:52
Message:
I fixed the issue for me with
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-completion/bash-completion.git;a=commit;h=60b8fabec499dbd56636548369ff3796e0d0d0fd
--
Comment By: Igor Murzov (garik-guest)
Date: 09/06/2014 23:33
Message:
The issue doesn't seem fixed for me.
--
Comment By: Ville Skyttä (scop-guest)
Date: 03/06/2014 22:15
Message:
Applied, thanks
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314709] -? triggers failglob if left unquoted
bash-completion-Bugs item #314709 was changed at 10/06/2014 15:22 by Dams Nadé
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114
Status: Closed
Priority: 3
Submitted By: Dams Nadé (anvil-guest)
Assigned to: Nobody (None)
Summary: -? triggers failglob if left unquoted
Distribution: None
Originally reported in: None
Milestone: 2.0
Status: Fix Committed
Original bug number:
Initial Comment:
Since '?' is a glob char, it needs to be quoted or an error will be triggered
when using failglob.
The ssh-add/ssh-keygen completions are broken due to this issue.
See attached trivial patch.
--
Comment By: Dams Nadé (anvil-guest)
Date: 10/06/2014 15:22
Message:
(this would of course require calling functions to honor this new signature. It
should only concern asciidoc cvs koji ssh-add ssh-keygen sysbench valgrind )
--
Comment By: Dams Nadé (anvil-guest)
Date: 10/06/2014 15:17
Message:
Hm, let's change the _parse_help signature, then ?
What about in _parse_help something like :
_parse_help()
{
eval local cmd=$( quote $1 )
local line
shift
local -a help_params
if [[ $# -ge 1 ]]
then
help_params=($@)
else
help_params=(--help)
fi
{ case $cmd in
-) cat ;;
*) LC_ALL=C $( dequote $cmd ) ${help_params[@]} 21 ;;
esac }
I really think relying on word-spliting is a bad bad thing
--
Comment By: Igor Murzov (garik-guest)
Date: 10/06/2014 15:09
Message:
I have tried to fix the issue this way. But some completions pass multiple
words as a help parameter. See completions/valgrind for example.
--
Comment By: Dams Nadé (anvil-guest)
Date: 10/06/2014 08:29
Message:
Please consider reverting your change and applying this patch instead.
--
Comment By: Dams Nadé (anvil-guest)
Date: 10/06/2014 08:24
Message:
If, this is not the way it should be fixed, IMHO. If it still fails, then the
problem is in _parse_help.
--
Comment By: Igor Murzov (garik-guest)
Date: 10/06/2014 00:52
Message:
I fixed the issue for me with
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-completion/bash-completion.git;a=commit;h=60b8fabec499dbd56636548369ff3796e0d0d0fd
--
Comment By: Igor Murzov (garik-guest)
Date: 09/06/2014 23:33
Message:
The issue doesn't seem fixed for me.
--
Comment By: Ville Skyttä (scop-guest)
Date: 03/06/2014 22:15
Message:
Applied, thanks
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314709] -? triggers failglob if left unquoted
bash-completion-Bugs item #314709 was changed at 2014-06-10 18:29 by Igor Murzov
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114
Status: Closed
Priority: 3
Submitted By: Dams Nadé (anvil-guest)
Assigned to: Nobody (None)
Summary: -? triggers failglob if left unquoted
Distribution: None
Originally reported in: None
Milestone: 2.0
Status: Fix Committed
Original bug number:
Initial Comment:
Since '?' is a glob char, it needs to be quoted or an error will be triggered
when using failglob.
The ssh-add/ssh-keygen completions are broken due to this issue.
See attached trivial patch.
--
Comment By: Igor Murzov (garik-guest)
Date: 2014-06-10 18:29
Message:
I'm ok with the proposed change. Will give it some testing and tell the result.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-10 17:22
Message:
(this would of course require calling functions to honor this new signature. It
should only concern asciidoc cvs koji ssh-add ssh-keygen sysbench valgrind )
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-10 17:17
Message:
Hm, let's change the _parse_help signature, then ?
What about in _parse_help something like :
_parse_help()
{
eval local cmd=$( quote $1 )
local line
shift
local -a help_params
if [[ $# -ge 1 ]]
then
help_params=($@)
else
help_params=(--help)
fi
{ case $cmd in
-) cat ;;
*) LC_ALL=C $( dequote $cmd ) ${help_params[@]} 21 ;;
esac }
I really think relying on word-spliting is a bad bad thing
--
Comment By: Igor Murzov (garik-guest)
Date: 2014-06-10 17:09
Message:
I have tried to fix the issue this way. But some completions pass multiple
words as a help parameter. See completions/valgrind for example.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-10 10:29
Message:
Please consider reverting your change and applying this patch instead.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-10 10:24
Message:
If, this is not the way it should be fixed, IMHO. If it still fails, then the
problem is in _parse_help.
--
Comment By: Igor Murzov (garik-guest)
Date: 2014-06-10 02:52
Message:
I fixed the issue for me with
https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-completion/bash-completion.git;a=commit;h=60b8fabec499dbd56636548369ff3796e0d0d0fd
--
Comment By: Igor Murzov (garik-guest)
Date: 2014-06-10 01:33
Message:
The issue doesn't seem fixed for me.
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-06-04 00:15
Message:
Applied, thanks
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314713] man completion is not failglob complaint
bash-completion-Bugs item #314713 was changed at 10/06/2014 19:21 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314713group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: man completion is not failglob complaint Distribution: None Originally reported in: None Milestone: 2.0 Status: Accepted Original bug number: Initial Comment: The man completion is not failglob compliant because it relies on way too much on glob patterns stored in parameters (which is not meant to be used that way). The attached patch propose ls-free nullglob-based more robust implementation. -- Comment By: Dams Nadé (anvil-guest) Date: 10/06/2014 19:21 Message: Hm, be careful, the last change of the patch is bad. $mansect should not be quoted. It's a pattern, and meant to be used unquoted inside [[ ]]. Sorry about that. -- Comment By: Igor Murzov (garik-guest) Date: 10/06/2014 00:23 Message: I can confirm that the patch fixes test failures for me :) -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314713group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314717] [PATCH] modprobe: fix params with multi-line descriptions
bash-completion-Bugs item #314717 was changed at 2014-06-09 09:41 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314717group_id=100114 Status: Closed Priority: 3 Submitted By: Peter Wu (lekensteyn-guest) Assigned to: Nobody (None) Summary: [PATCH] modprobe: fix params with multi-line descriptions Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: Fix Committed Original bug number: Initial Comment: The command `nouveau -p nouveau` outputs: tv_norm:Default TV norm. Supported: PAL, PAL-M, PAL-N, PAL-Nc, NTSC-M, NTSC-J, hd480i, hd480p, hd576i, hd576p, hd720p, hd1080i. Default: PAL *NOTE* Ignored for cards with external TV encoders. (charp) tv_disable:Disable TV-out detection (int) ... This breaks module parameter auto-completion, so only suggest parameters which are not preceded by a tab character. Tested with kmod 17-1 on Arch Linux. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-09 09:41 Message: Applied with minor modifications, thanks -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314717group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314652] [patch] add support for the new apt command
bash-completion-Bugs item #314652 was changed at 2014-06-09 09:32 by Ritesh Raj Sarraf You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314652group_id=100114 Status: Open Priority: 3 Submitted By: Michael Vogt (mvo) Assigned to: Nobody (None) Summary: [patch] add support for the new apt command Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Attached is a bash completion file for the new apt binary found in debian and ubuntu. It is slightly different than the existing apt-get/apt-cache completions in that it tries to present only --options that are specific to the commands. Feedback very welcome! Thanks, Michael -- Comment By: Ritesh Raj Sarraf (rrs) Date: 2014-06-09 09:32 Message: Thank you for this patch. Is there a reason why this is not pushed into the Debian archive ? Without autocompletion, precious time is wasted... -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314652group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314720] set -o posix in test/config/bashrc breaks bash-valid code.
bash-completion-Bugs item #314720, was opened at 09/06/2014 21:22 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314720group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: set -o posix in test/config/bashrc breaks bash-valid code. Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: #314716, I've submitted a function with a () construction. While this is valid bash syntax, it cannot be parsed by bash if posix mode is enabled. I would say set -o posix plays against the Use the full power of bash = 4.1 statement from the README file, CONTRIBUTING section. Since a lot of bash completion code is not POSIX compliant ([[, arrays, extglob, etc), I would suggest *disabling* posix mode in the test suite bashrc configuration file. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314720group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314710] badly-quoted-then-evaled var in _filedir_xspec triggers failglob
bash-completion-Bugs item #314710 was changed at 2014-06-10 01:20 by Igor Murzov You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314710group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: badly-quoted-then-evaled var in _filedir_xspec triggers failglob Distribution: None Originally reported in: None Milestone: 2.0 Status: Fix Committed Original bug number: Initial Comment: I've managed to fix 7z/vi/acroread test cases with failglob enabled by simply adding a pair of simple quotes in _filedir_xspec. The proper way would be to remove the eval in this line (see attached patch) instead, but my knowledge of the compgen/quote_readline combo is kinda limited. -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-10 01:20 Message: Looks like the issue is fixed in https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-completion/bash-completion.git;a=commit;h=b65232fa34e310cf357e2ff4b8921e50e260d294 Closing the ticket now. Thanks for the patch. -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-04 23:39 Message: Here is the git format-patch version of the patch. Thank you for your patience. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314710group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314709] -? triggers failglob if left unquoted
bash-completion-Bugs item #314709 was changed at 2014-06-10 01:33 by Igor Murzov You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: -? triggers failglob if left unquoted Distribution: None Originally reported in: None Milestone: 2.0 Status: Accepted Original bug number: Initial Comment: Since '?' is a glob char, it needs to be quoted or an error will be triggered when using failglob. The ssh-add/ssh-keygen completions are broken due to this issue. See attached trivial patch. -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-10 01:33 Message: The issue doesn't seem fixed for me. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-04 00:15 Message: Applied, thanks -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314713] man completion is not failglob complaint
bash-completion-Bugs item #314713 was changed at 2014-06-10 02:23 by Igor Murzov You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314713group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: man completion is not failglob complaint Distribution: None Originally reported in: None Milestone: 2.0 Status: Accepted Original bug number: Initial Comment: The man completion is not failglob compliant because it relies on way too much on glob patterns stored in parameters (which is not meant to be used that way). The attached patch propose ls-free nullglob-based more robust implementation. -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-10 02:23 Message: I can confirm that the patch fixes test failures for me :) -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314713group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314709] -? triggers failglob if left unquoted
bash-completion-Bugs item #314709 was changed at 2014-06-10 02:52 by Igor Murzov You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: -? triggers failglob if left unquoted Distribution: None Originally reported in: None Milestone: 2.0 Status: Fix Committed Original bug number: Initial Comment: Since '?' is a glob char, it needs to be quoted or an error will be triggered when using failglob. The ssh-add/ssh-keygen completions are broken due to this issue. See attached trivial patch. -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-10 02:52 Message: I fixed the issue for me with https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-completion/bash-completion.git;a=commit;h=60b8fabec499dbd56636548369ff3796e0d0d0fd -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-10 01:33 Message: The issue doesn't seem fixed for me. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-04 00:15 Message: Applied, thanks -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314707] shopt -s failglob breaks _parse_help
bash-completion-Bugs item #314707 was changed at 2014-06-09 01:54 by Igor Murzov
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314707group_id=100114
Status: Closed
Priority: 3
Submitted By: Ville Skyttä (scop-guest)
Assigned to: Nobody (None)
Summary: shopt -s failglob breaks _parse_help
Distribution: None
Originally reported in: None
Milestone: None
Status: Fix Committed
Original bug number:
Initial Comment:
With shopt -s failglob in test/config/bashrc:
$ ./runUnit _parse_help.exp
[...]
Running ./unit/_parse_help.exp ...
FAIL: long with value and eq sign in brackets
FAIL: long with [no]
FAIL: long with [no-] + optional arg
FAIL: long with [no-] + required arg
FAIL: long with [dont-]
FAIL: short and long with [dont]
FAIL: -f [FOO], --foo[=FOO]
Haven't investigated if this is real breakage or if it's just the test case
that gets broken somehow.
--
Comment By: Igor Murzov (garik-guest)
Date: 2014-06-09 01:54
Message:
Thanks for the patch, Damien. Fix commited.
--
Comment By: Igor Murzov (garik-guest)
Date: 2014-06-05 00:37
Message:
Looks good to me.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-02 22:12
Message:
Found an issue, located in __parse_options. One should never do for i in $var
nor for i in $(cmd).
I cant seem to attach any document, so here's the inlined patch :
diff --git a/bash_completion b/bash_completion
index 3e5c813..d61b257 100644
--- a/bash_completion
+++ b/bash_completion
@@ -742,8 +742,10 @@ __parse_options()
# Take first found long option, or first one (short) if not found.
option=
-for i in $1; do
-case $i in
+local -a array
+read -a array $1
+for i in ${array[@]}; do
+case $i in
---*) break ;;
--?*) option=$i ; break ;;
-?*) [[ $option ]] || option=$i ;;
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314707group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314716] LVM completion fixes and enhancements (failglob, sizes...)
bash-completion-Bugs item #314716 was changed at 2014-06-07 12:35 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314716group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: LVM completion fixes and enhancements (failglob, sizes...) Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Please find attached 3 patches for LVM : * 0001-lvm-_lvm_count_args-parameter-must-be-quoted-in-orde.patch : In completions/lvm, the _lvm_count_args functions takes a pattern as parameter. In the rest of the file, the given parameter is not correctly quoted. * 0002-lvm-_lvm-using-a-single-pattern-case-and-invoking-fu.patch A purely esthetic change, which shortens the 'case' statement in _lvm. * 0003-lvm-_lvm_sizes-new-implementation-able-to-handle-rel.patch A new implementation for _lvm_sizes. This should fix the relative-size completion issue described in [#311391]. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-07 12:35 Message: 0001 and 0002 (with slight modifications) applied, hopefully someone who actually uses lvm will take a look at the rest. -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-07 01:41 Message: 0005-lvm-dynamically-compute-the-available-field-names-fo.patch : The currently provided list of field names for pvs/lvs/vgs is incomplete. I suggest parsing these commands stderr to compute the full list of available fields, thus enhancing the completion. -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-07 00:49 Message: * 0004-lvm-using-vgs-pvs-lvs-in-_lvm_volumegroups-_lvm_phys.patch We can remove the use of sed in the functions providing pv/vg/lv names by using pvs/vgs/lvs instead of pvscan/vgscan/lvscan. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314716group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314714] gendiff and sqlite3 are broken with failglob
bash-completion-Bugs item #314714 was changed at 06/06/2014 20:30 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314714group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: gendiff and sqlite3 are broken with failglob Distribution: None Originally reported in: None Milestone: None Status: Accepted Original bug number: Initial Comment: When enabling failglob, gendiff [TAB] prints an error. I've managed to trace this error in both the completion/gendiff file and in _init_completion function in bash_completion. See the attached patches, it's pretty straightforward. The 3rd patch fixes the same kind of issue for the sqlite3 completion. -- Comment By: Dams Nadé (anvil-guest) Date: 06/06/2014 20:30 Message: Thank you. -- Comment By: Dams Nadé (anvil-guest) Date: 05/06/2014 22:24 Message: No, the sqlite3 patch is not required anymore. It's included among things Igor has changed earlier. sqlite3 [TAB] was just failing to me when failglob was enabled. -- Comment By: Ville Skyttä (scop-guest) Date: 05/06/2014 21:54 Message: gendiff patch applied with minor change in commit message; we like them to contain some identification about affected things usually in the form of prefix in the message so one can see what a commit affects just by looking at the message. Is the third patch still needed? If yes, could you provide a recipe how to trigger an issue when it's not applied? -- Comment By: Dams Nadé (anvil-guest) Date: 05/06/2014 09:11 Message: It seems Igor Murzov fixed a bunch of this issues in the git a few hours ago. gendiff is still broken though. :-) -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314714group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314715] Please use doxygen for API documentation
bash-completion-Bugs item #314715 was changed at 06/06/2014 22:31 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314715group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: Please use doxygen for API documentation Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: I would like to suggest using doxygen for the bash-completion project. I have documented my own bash library (bash-argsparse) with it and the result is pretty convincing to me. The result is available at http://argsparse.livna.org/doxygen/ Also please check : * the original library source code, with inline documentation at https://github.com/Anvil/bash-argsparse/blob/master/argsparse.sh * the doxygen configuration file used in the process https://github.com/Anvil/bash-argsparse/blob/master/Doxyfile * and at last the doxygen filter file which makes all this possible. https://github.com/Anvil/bash-argsparse/blob/master/doxygen-bash.sed The filter is potentially a bit limted, but either the filter or the source code can be adapted without too much trouble, I think. If you are ok with that, I would like to start providing some patches for bash_completion. Me documenting functions could hepl improve my understanding of the internal magic involved in the bash_completion and provide better contributions. Feel free to ask me any question about this. -- Comment By: Dams Nadé (anvil-guest) Date: 06/06/2014 22:31 Message: More exactly the library documentation is available at http://argsparse.livna.org/doxygen/argsparse_8sh.html -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314715group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314716] LVM completion fixes and enhancements (failglob, sizes...)
bash-completion-Bugs item #314716, was opened at 06/06/2014 23:14 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314716group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: LVM completion fixes and enhancements (failglob, sizes...) Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Please find attached 3 patches for LVM : * 0001-lvm-_lvm_count_args-parameter-must-be-quoted-in-orde.patch : In completions/lvm, the _lvm_count_args functions takes a pattern as parameter. In the rest of the file, the given parameter is not correctly quoted. * 0002-lvm-_lvm-using-a-single-pattern-case-and-invoking-fu.patch A purely esthetic change, which shortens the 'case' statement in _lvm. * 0003-lvm-_lvm_sizes-new-implementation-able-to-handle-rel.patch A new implementation for _lvm_sizes. This should fix the relative-size completion issue described in [#311391]. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314716group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314716] LVM completion fixes and enhancements (failglob, sizes...)
bash-completion-Bugs item #314716 was changed at 06/06/2014 23:49 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314716group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: LVM completion fixes and enhancements (failglob, sizes...) Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Please find attached 3 patches for LVM : * 0001-lvm-_lvm_count_args-parameter-must-be-quoted-in-orde.patch : In completions/lvm, the _lvm_count_args functions takes a pattern as parameter. In the rest of the file, the given parameter is not correctly quoted. * 0002-lvm-_lvm-using-a-single-pattern-case-and-invoking-fu.patch A purely esthetic change, which shortens the 'case' statement in _lvm. * 0003-lvm-_lvm_sizes-new-implementation-able-to-handle-rel.patch A new implementation for _lvm_sizes. This should fix the relative-size completion issue described in [#311391]. -- Comment By: Dams Nadé (anvil-guest) Date: 06/06/2014 23:49 Message: * 0004-lvm-using-vgs-pvs-lvs-in-_lvm_volumegroups-_lvm_phys.patch We can remove the use of sed in the functions providing pv/vg/lv names by using pvs/vgs/lvs instead of pvscan/vgscan/lvscan. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314716group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314716] LVM completion fixes and enhancements (failglob, sizes...)
bash-completion-Bugs item #314716 was changed at 07/06/2014 00:41 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314716group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: LVM completion fixes and enhancements (failglob, sizes...) Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Please find attached 3 patches for LVM : * 0001-lvm-_lvm_count_args-parameter-must-be-quoted-in-orde.patch : In completions/lvm, the _lvm_count_args functions takes a pattern as parameter. In the rest of the file, the given parameter is not correctly quoted. * 0002-lvm-_lvm-using-a-single-pattern-case-and-invoking-fu.patch A purely esthetic change, which shortens the 'case' statement in _lvm. * 0003-lvm-_lvm_sizes-new-implementation-able-to-handle-rel.patch A new implementation for _lvm_sizes. This should fix the relative-size completion issue described in [#311391]. -- Comment By: Dams Nadé (anvil-guest) Date: 07/06/2014 00:41 Message: 0005-lvm-dynamically-compute-the-available-field-names-fo.patch : The currently provided list of field names for pvs/lvs/vgs is incomplete. I suggest parsing these commands stderr to compute the full list of available fields, thus enhancing the completion. -- Comment By: Dams Nadé (anvil-guest) Date: 06/06/2014 23:49 Message: * 0004-lvm-using-vgs-pvs-lvs-in-_lvm_volumegroups-_lvm_phys.patch We can remove the use of sed in the functions providing pv/vg/lv names by using pvs/vgs/lvs instead of pvscan/vgscan/lvscan. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314716group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314714] gendiff and sqlite3 are broken with failglob
bash-completion-Bugs item #314714 was changed at 05/06/2014 22:24 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314714group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: gendiff and sqlite3 are broken with failglob Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: When enabling failglob, gendiff [TAB] prints an error. I've managed to trace this error in both the completion/gendiff file and in _init_completion function in bash_completion. See the attached patches, it's pretty straightforward. The 3rd patch fixes the same kind of issue for the sqlite3 completion. -- Comment By: Dams Nadé (anvil-guest) Date: 05/06/2014 22:24 Message: No, the sqlite3 patch is not required anymore. It's included among things Igor has changed earlier. sqlite3 [TAB] was just failing to me when failglob was enabled. -- Comment By: Ville Skyttä (scop-guest) Date: 05/06/2014 21:54 Message: gendiff patch applied with minor change in commit message; we like them to contain some identification about affected things usually in the form of prefix in the message so one can see what a commit affects just by looking at the message. Is the third patch still needed? If yes, could you provide a recipe how to trigger an issue when it's not applied? -- Comment By: Dams Nadé (anvil-guest) Date: 05/06/2014 09:11 Message: It seems Igor Murzov fixed a bunch of this issues in the git a few hours ago. gendiff is still broken though. :-) -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314714group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314714] gendiff and sqlite3 are broken with failglob
bash-completion-Bugs item #314714 was changed at 2014-06-06 08:54 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314714group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: gendiff and sqlite3 are broken with failglob Distribution: None Originally reported in: None Milestone: None Status: Accepted Original bug number: Initial Comment: When enabling failglob, gendiff [TAB] prints an error. I've managed to trace this error in both the completion/gendiff file and in _init_completion function in bash_completion. See the attached patches, it's pretty straightforward. The 3rd patch fixes the same kind of issue for the sqlite3 completion. -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-05 23:24 Message: No, the sqlite3 patch is not required anymore. It's included among things Igor has changed earlier. sqlite3 [TAB] was just failing to me when failglob was enabled. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-05 22:54 Message: gendiff patch applied with minor change in commit message; we like them to contain some identification about affected things usually in the form of prefix in the message so one can see what a commit affects just by looking at the message. Is the third patch still needed? If yes, could you provide a recipe how to trigger an issue when it's not applied? -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-05 10:11 Message: It seems Igor Murzov fixed a bunch of this issues in the git a few hours ago. gendiff is still broken though. :-) -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314714group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314710] badly-quoted-then-evaled var in _filedir_xspec triggers failglob
bash-completion-Bugs item #314710 was changed at 04/06/2014 21:39 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314710group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: badly-quoted-then-evaled var in _filedir_xspec triggers failglob Distribution: None Originally reported in: None Milestone: 2.0 Status: None Original bug number: Initial Comment: I've managed to fix 7z/vi/acroread test cases with failglob enabled by simply adding a pair of simple quotes in _filedir_xspec. The proper way would be to remove the eval in this line (see attached patch) instead, but my knowledge of the compgen/quote_readline combo is kinda limited. -- Comment By: Dams Nadé (anvil-guest) Date: 04/06/2014 21:39 Message: Here is the git format-patch version of the patch. Thank you for your patience. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314710group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314713] man completion is not failglob complaint
bash-completion-Bugs item #314713, was opened at 04/06/2014 21:49 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314713group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: man completion is not failglob complaint Distribution: None Originally reported in: None Milestone: 2.0 Status: None Original bug number: Initial Comment: The man completion is not failglob compliant because it relies on way too much on glob patterns stored in parameters (which is not meant to be used that way). The attached patch propose ls-free nullglob-based more robust implementation. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314713group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314707] shopt -s failglob breaks _parse_help
bash-completion-Bugs item #314707 was changed at 2014-06-05 00:37 by Igor Murzov
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314707group_id=100114
Status: Open
Priority: 3
Submitted By: Ville Skyttä (scop-guest)
Assigned to: Nobody (None)
Summary: shopt -s failglob breaks _parse_help
Distribution: None
Originally reported in: None
Milestone: None
Status: Accepted
Original bug number:
Initial Comment:
With shopt -s failglob in test/config/bashrc:
$ ./runUnit _parse_help.exp
[...]
Running ./unit/_parse_help.exp ...
FAIL: long with value and eq sign in brackets
FAIL: long with [no]
FAIL: long with [no-] + optional arg
FAIL: long with [no-] + required arg
FAIL: long with [dont-]
FAIL: short and long with [dont]
FAIL: -f [FOO], --foo[=FOO]
Haven't investigated if this is real breakage or if it's just the test case
that gets broken somehow.
--
Comment By: Igor Murzov (garik-guest)
Date: 2014-06-05 00:37
Message:
Looks good to me.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-02 22:12
Message:
Found an issue, located in __parse_options. One should never do for i in $var
nor for i in $(cmd).
I cant seem to attach any document, so here's the inlined patch :
diff --git a/bash_completion b/bash_completion
index 3e5c813..d61b257 100644
--- a/bash_completion
+++ b/bash_completion
@@ -742,8 +742,10 @@ __parse_options()
# Take first found long option, or first one (short) if not found.
option=
-for i in $1; do
-case $i in
+local -a array
+read -a array $1
+for i in ${array[@]}; do
+case $i in
---*) break ;;
--?*) option=$i ; break ;;
-?*) [[ $option ]] || option=$i ;;
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314707group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314714] gendiff and sqlite3 are broken with failglob
bash-completion-Bugs item #314714, was opened at 04/06/2014 23:23 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314714group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: gendiff and sqlite3 are broken with failglob Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: When enabling failglob, gendiff [TAB] prints an error. I've managed to trace this error in both the completion/gendiff file and in _init_completion function in bash_completion. See the attached patches, it's pretty straightforward. The 3rd patch fixes the same kind of issue for the sqlite3 completion. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314714group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314708] Array element unset needs to be quoted
bash-completion-Bugs item #314708 was changed at 2014-06-03 13:55 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314708group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: Array element unset needs to be quoted Distribution: None Originally reported in: None Milestone: 2.0 Status: None Original bug number: Initial Comment: unsetting an array element needs to be quoted to prevent globbing to interfer. See this example : [anvil@tartine ~/git/bash-completion]# LC_ALL=en_US bash [anvil@tartine bash-completion]$ shopt -s failglob [anvil@tartine bash-completion]$ foo=(1 2 3) [anvil@tartine bash-completion]$ unset foo[1] bash: no match: foo[1] [anvil@tartine bash-completion]$ unset 'foo[1]' ; echo $? 0 Please consider applying attached patch, which fixes a bunch of issues when using failglob. Without attached patch : -# of expected passes 648 -# of unexpected failures 45 -# of unresolved testcases 33 With : +# of expected passes 673 +# of unexpected failures 23 +# of unresolved testcases 29 -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-03 13:55 Message: When I tested this yesterday, I found that quoting it also failed to actually unset anything. Now I can't reproduce that finding, I suppose I did something silly/faulty. Looks like the bash man page contains a subtle hint about the necessity of quoting: unset name[subscript] destroys the array element at index subscript. Care must be taken to avoid unwanted side effects caused by pathname expansion. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314708group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314703] README says to run included configure script, but none is included
bash-completion-Bugs item #314703 was changed at 2014-06-03 14:34 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314703group_id=100114 Status: Closed Priority: 3 Submitted By: Ian Kelling (iankelling-guest) Assigned to: Nobody (None) Summary: README says to run included configure script, but none is included Distribution: None Originally reported in: None Milestone: None Status: Invalid Original bug number: Initial Comment: No configure script is included, yet the README file states: If you don't have the package readily available for your distribution, or you simply don't want to use one, you can install bash completion using the standard commands for GNU autotools packages: ./configure make make check # optional, requires dejagnu and tcllib make install # as root -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-03 14:34 Message: There's some discussion about this on the mailing list today. But anyway, bootstrapping an autotools project usually starts with for example running autoreconf -i. You'll probably need a bunch of packages installed (automake, autoconf, etc etc). I'm not going to even try to write a autotools tutorial here or elsewhere, autoreconf should tell you what you're missing, if anything. Another alternative to autotools stuff, especially if you're just testing a git snapshot for yourself, is just to use it, no need to bother with installing it. For example I have my git clone in my ~/cvs/bash-completion dir, and this in my ~/.bashrc: [[ $PS1 !$BASH_COMPLETION_COMPAT_DIR ]] \ . ~/cvs/bash-completion/bash_completion On the other hand we do set up a bunch of symlinks in the completions dir during make which requires an autotools-bootstrapped (and configured) dir, so at least that part of the setup will be incomplete if you don't do it. But it's good enough to test many things. If someone wants to submit a patch to let's say README based on this discussion, feel free. -- Comment By: Ian! D. Allen (idallen-guest) Date: 2014-06-02 20:08 Message: Please tell me or point me at documentation on how to install and test the current snapshot, if following the README won't work. I don't speak git much yet, but I see that I can get a lovely tarball snapshot, that I can't install and use because the included documentation is wrong for that kind of tarball. Perhaps you could create a README_GIT_SNAPSHOT to help those of us who are trying to help you test the software? -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-01 15:38 Message: README documents setup from release tarball, the script is included in it and intentionally not in git. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314703group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314708] Array element unset needs to be quoted
bash-completion-Bugs item #314708 was changed at 03/06/2014 22:00 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314708group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: Array element unset needs to be quoted Distribution: None Originally reported in: None Milestone: 2.0 Status: None Original bug number: Initial Comment: unsetting an array element needs to be quoted to prevent globbing to interfer. See this example : [anvil@tartine ~/git/bash-completion]# LC_ALL=en_US bash [anvil@tartine bash-completion]$ shopt -s failglob [anvil@tartine bash-completion]$ foo=(1 2 3) [anvil@tartine bash-completion]$ unset foo[1] bash: no match: foo[1] [anvil@tartine bash-completion]$ unset 'foo[1]' ; echo $? 0 Please consider applying attached patch, which fixes a bunch of issues when using failglob. Without attached patch : -# of expected passes 648 -# of unexpected failures 45 -# of unresolved testcases 33 With : +# of expected passes 673 +# of unexpected failures 23 +# of unresolved testcases 29 -- Comment By: Dams Nadé (anvil-guest) Date: 03/06/2014 22:00 Message: Here is a second patch, with the same problem, this time in completion files. It fixes crontab, cvs, badblocks, find, info, lvm, modprobe, protoc and qdbus when used with failglob. -- Comment By: Ville Skyttä (scop-guest) Date: 03/06/2014 12:55 Message: When I tested this yesterday, I found that quoting it also failed to actually unset anything. Now I can't reproduce that finding, I suppose I did something silly/faulty. Looks like the bash man page contains a subtle hint about the necessity of quoting: unset name[subscript] destroys the array element at index subscript. Care must be taken to avoid unwanted side effects caused by pathname expansion. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314708group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314708] Array element unset needs to be quoted
bash-completion-Bugs item #314708 was changed at 2014-06-03 23:12 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314708group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: Array element unset needs to be quoted Distribution: None Originally reported in: None Milestone: 2.0 Status: Fix Committed Original bug number: Initial Comment: unsetting an array element needs to be quoted to prevent globbing to interfer. See this example : [anvil@tartine ~/git/bash-completion]# LC_ALL=en_US bash [anvil@tartine bash-completion]$ shopt -s failglob [anvil@tartine bash-completion]$ foo=(1 2 3) [anvil@tartine bash-completion]$ unset foo[1] bash: no match: foo[1] [anvil@tartine bash-completion]$ unset 'foo[1]' ; echo $? 0 Please consider applying attached patch, which fixes a bunch of issues when using failglob. Without attached patch : -# of expected passes 648 -# of unexpected failures 45 -# of unresolved testcases 33 With : +# of expected passes 673 +# of unexpected failures 23 +# of unresolved testcases 29 -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-03 23:12 Message: Applied, thanks -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-03 23:00 Message: Here is a second patch, with the same problem, this time in completion files. It fixes crontab, cvs, badblocks, find, info, lvm, modprobe, protoc and qdbus when used with failglob. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-03 13:55 Message: When I tested this yesterday, I found that quoting it also failed to actually unset anything. Now I can't reproduce that finding, I suppose I did something silly/faulty. Looks like the bash man page contains a subtle hint about the necessity of quoting: unset name[subscript] destroys the array element at index subscript. Care must be taken to avoid unwanted side effects caused by pathname expansion. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314708group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314709] -? triggers failglob if left unquoted
bash-completion-Bugs item #314709 was changed at 2014-06-03 23:15 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: -? triggers failglob if left unquoted Distribution: None Originally reported in: None Milestone: 2.0 Status: Accepted Original bug number: Initial Comment: Since '?' is a glob char, it needs to be quoted or an error will be triggered when using failglob. The ssh-add/ssh-keygen completions are broken due to this issue. See attached trivial patch. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-03 23:15 Message: Applied, thanks -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314708] Array element unset needs to be quoted
bash-completion-Bugs item #314708 was changed at 2014-06-03 23:24 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314708group_id=100114 Status: Closed Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: Array element unset needs to be quoted Distribution: None Originally reported in: None Milestone: 2.0 Status: Fix Committed Original bug number: Initial Comment: unsetting an array element needs to be quoted to prevent globbing to interfer. See this example : [anvil@tartine ~/git/bash-completion]# LC_ALL=en_US bash [anvil@tartine bash-completion]$ shopt -s failglob [anvil@tartine bash-completion]$ foo=(1 2 3) [anvil@tartine bash-completion]$ unset foo[1] bash: no match: foo[1] [anvil@tartine bash-completion]$ unset 'foo[1]' ; echo $? 0 Please consider applying attached patch, which fixes a bunch of issues when using failglob. Without attached patch : -# of expected passes 648 -# of unexpected failures 45 -# of unresolved testcases 33 With : +# of expected passes 673 +# of unexpected failures 23 +# of unresolved testcases 29 -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-03 23:24 Message: Oh, looks like I beat you to the 2nd patch -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-03 23:12 Message: Applied, thanks -- Comment By: Dams Nadé (anvil-guest) Date: 2014-06-03 23:00 Message: Here is a second patch, with the same problem, this time in completion files. It fixes crontab, cvs, badblocks, find, info, lvm, modprobe, protoc and qdbus when used with failglob. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-03 13:55 Message: When I tested this yesterday, I found that quoting it also failed to actually unset anything. Now I can't reproduce that finding, I suppose I did something silly/faulty. Looks like the bash man page contains a subtle hint about the necessity of quoting: unset name[subscript] destroys the array element at index subscript. Care must be taken to avoid unwanted side effects caused by pathname expansion. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314708group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314704] autoconf fails
bash-completion-Bugs item #314704 was changed at 2014-06-02 10:57 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314704group_id=100114 Status: Closed Priority: 3 Submitted By: Ian Kelling (iankelling-guest) Assigned to: Nobody (None) Summary: autoconf fails Distribution: Debian Originally reported in: None Milestone: None Status: Invalid Original bug number: Initial Comment: from git commit 54d53c622. Doesn't happen on the stable version 2.1 on debian wheezy output from autoconf: configure.ac:3: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-02 10:57 Message: Install automake. BTW use autoreconf instead of autoconf and all other needed tools individually, it'll also run them in the correct order. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314704group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314702] Puppet enhancements
bash-completion-Bugs item #314702 was changed at 2014-06-02 12:45 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314702group_id=100114 Status: Closed Priority: 3 Submitted By: Mathieu Parent (sathieu) Assigned to: Nobody (None) Summary: Puppet enhancements Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: Fix Committed Original bug number: Initial Comment: See attachements which improve the puppet support -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-02 12:45 Message: All applied (parser one with s/pupper/puppet/ typo fix), plus some additional ones. See also https://github.com/puppetlabs/puppet/pull/2718 -- Comment By: Mathieu Parent (sathieu) Date: 2014-05-30 17:15 Message: There are 7 patches. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314702group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][312741] shopt -s failglob breaks __reassemble_comp_words_by_ref
bash-completion-Bugs item #312741 was changed at 02/06/2014 15:00 by Dams Nadé
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=312741group_id=100114
Status: Open
Priority: 3
Submitted By: Ville Skyttä (scop-guest)
Assigned to: Nobody (None)
Summary: shopt -s failglob breaks __reassemble_comp_words_by_ref
Distribution: None
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
$ shopt -s failglob
$ ssh TABbash: no match: words[0]=${!ref}${COMP_WORDS[i]}
http://thread.gmane.org/gmane.comp.shells.bash.completion.devel/2546
--
Comment By: Dams Nadé (anvil-guest)
Date: 02/06/2014 15:00
Message:
Ville, I use failglob on a daily basis and the (poorly-pasted - sorry about
that) patch I've put has been working for a couple of years, now.
Any chance we can see this applied in the git ? If you can still failures after
that you can count me in for a troubleshooting/debugging session.
--
Comment By: Dams Nadé (anvil-guest)
Date: 17/02/2014 14:03
Message:
I got this patch, here to solve this issue i think :
diff -u --exclude CVS --exclude .svn --exclude .bzr --exclude .pc --exclude
test --exclude completions --exclude debian -ub
bash-completion-1.3.orig/bash_completion bash-completion-1.3/bash_completion
--- bash-completion-1.3.orig/bash_completion2013-09-12 16:06:45.0
+0200
+++ bash-completion-1.3/bash_completion 2013-09-12 17:25:19.0 +0200
@@ -286,7 +286,7 @@
fi
# Default to cword unchanged
-eval $3=$COMP_CWORD
+printf -v $3 %s $COMP_CWORD
# Are characters excluded which were former included?
if [[ $exclude ]]; then
# Yes, list of word completion separators has shrunk;
@@ -296,26 +296,28 @@
# empty and is word made up of just word separator characters to be
# excluded?
while [[ $i -gt 0 ${COMP_WORDS[$i]}
-${COMP_WORDS[$i]//[^$exclude]} == ${COMP_WORDS[$i]}
+${COMP_WORDS[$i]//[^$exclude]} = ${COMP_WORDS[$i]}
]]; do
[ $j -ge 2 ] ((j--))
# Append word separator to current word
ref=$2[$j]
-eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
+printf -v $ref %s ${!ref}${COMP_WORDS[i]}
# Indicate new cword
-[ $i = $COMP_CWORD ] eval $3=$j
+[ $i = $COMP_CWORD ] printf -v $3 %s $j
# Indicate next word if available, else end *both* while and
for loop
(( $i ${#COMP_WORDS[@]} - 1)) ((i++)) || break 2
done
# Append word to current word
ref=$2[$j]
-eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
+printf -v $ref %s ${!ref}${COMP_WORDS[i]}
# Indicate new cword
-[[ $i == $COMP_CWORD ]] eval $3=$j
+[[ $i == $COMP_CWORD ]] printf -v $3 %s $j
done
else
# No, list of word completions separators hasn't changed;
-eval $2=\( \\${COMP_WORDS[@]}\ \)
+for i in ${!COMP_WORDS[@]}; do
+printf -v $2[i] %s ${COMP_WORDS[i]}
+done
fi
} # __reassemble_comp_words_by_ref()
@@ -1481,7 +1483,7 @@
COMP_WORDS[i]=${COMP_WORDS[i+$word_offset]}
done
for (( i; i = COMP_CWORD; i++ )); do
-unset COMP_WORDS[i];
+unset 'COMP_WORDS[i]'
done
COMP_CWORD=$(( $COMP_CWORD - $word_offset ))
--
Comment By: Dams Nadé (anvil-guest)
Date: 17/02/2014 13:49
Message:
A better eval-free approach would be to simple do
printf -v $2 %s ${!ref}${COMP_WORDS[i]}
It's faster and more secure this way, imho.
--
Comment By: Ville Skyttä (scop-guest)
Date: 17/02/2014 13:45
Message:
Unfortunately __reassemble_comp_words_by_ref is not the only thing affected by
failglob. At least all _install_xspec ones and ipmitool are, and I don't know
of a good recipe how to detect/grep an exhaustive list.
One approach for better-than-nothing coverage is to set shopt -s failglob in
our test suite's test/config/bashrc and start working on the failures it causes
there.
--
Comment By: Isaac Jurado (etanol-guest)
Date: 17/02/2014 11:57
Message:
I found this issue too (using 2.0 from Ubuntu Saucy). There is actually a very
simple fix that allows you to have failglob enabled with bash_completion
included too.
The trick is to temporarily disable failglob while executing the
__reassemble_comp_words_by_ref and then restoring it, in case it was disabled:
--- /usr/share/bash-completion/bash_completion.orig 2014-02-17
11:44:05.879501602 +0100
[Bash-completion-devel] [bash-completion-Bugs][314707] shopt -s failglob breaks _parse_help
bash-completion-Bugs item #314707, was opened at 2014-06-02 17:14 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314707group_id=100114 Status: Open Priority: 3 Submitted By: Ville Skyttä (scop-guest) Assigned to: Nobody (None) Summary: shopt -s failglob breaks _parse_help Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: With shopt -s failglob in test/config/bashrc: $ ./runUnit _parse_help.exp [...] Running ./unit/_parse_help.exp ... FAIL: long with value and eq sign in brackets FAIL: long with [no] FAIL: long with [no-] + optional arg FAIL: long with [no-] + required arg FAIL: long with [dont-] FAIL: short and long with [dont] FAIL: -f [FOO], --foo[=FOO] Haven't investigated if this is real breakage or if it's just the test case that gets broken somehow. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314707group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][312741] shopt -s failglob breaks __reassemble_comp_words_by_ref
bash-completion-Bugs item #312741 was changed at 2014-06-02 17:19 by Ville
Skyttä
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=312741group_id=100114
Status: Closed
Priority: 3
Submitted By: Ville Skyttä (scop-guest)
Assigned to: Nobody (None)
Summary: shopt -s failglob breaks __reassemble_comp_words_by_ref
Distribution: None
Originally reported in: None
Milestone: None
Status: Fix Committed
Original bug number:
Initial Comment:
$ shopt -s failglob
$ ssh TABbash: no match: words[0]=${!ref}${COMP_WORDS[i]}
http://thread.gmane.org/gmane.comp.shells.bash.completion.devel/2546
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-06-02 17:19
Message:
It doesn't seem to break anything and fixes a bunch of unit tests with failglob
on, so I've committed a slightly modified version of Dams' patch (dropped one
no-op cosmetic hunk and another which seems unrelated and broken):
http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=732906b25096508fbc5d15d684dea0312ed7fca0
However, there are still some bits to iron out with failglob on. I've filed
#314707 to track at least one, I suppose a bunch of others are still lurking
there and can be found if running the completion tests with failglob on:
https://alioth.debian.org/tracker/index.php?func=detailaid=314707group_id=100114atid=413095
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-06-02 16:00
Message:
Ville, I use failglob on a daily basis and the (poorly-pasted - sorry about
that) patch I've put has been working for a couple of years, now.
Any chance we can see this applied in the git ? If you can still failures after
that you can count me in for a troubleshooting/debugging session.
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-02-17 15:03
Message:
I got this patch, here to solve this issue i think :
diff -u --exclude CVS --exclude .svn --exclude .bzr --exclude .pc --exclude
test --exclude completions --exclude debian -ub
bash-completion-1.3.orig/bash_completion bash-completion-1.3/bash_completion
--- bash-completion-1.3.orig/bash_completion2013-09-12 16:06:45.0
+0200
+++ bash-completion-1.3/bash_completion 2013-09-12 17:25:19.0 +0200
@@ -286,7 +286,7 @@
fi
# Default to cword unchanged
-eval $3=$COMP_CWORD
+printf -v $3 %s $COMP_CWORD
# Are characters excluded which were former included?
if [[ $exclude ]]; then
# Yes, list of word completion separators has shrunk;
@@ -296,26 +296,28 @@
# empty and is word made up of just word separator characters to be
# excluded?
while [[ $i -gt 0 ${COMP_WORDS[$i]}
-${COMP_WORDS[$i]//[^$exclude]} == ${COMP_WORDS[$i]}
+${COMP_WORDS[$i]//[^$exclude]} = ${COMP_WORDS[$i]}
]]; do
[ $j -ge 2 ] ((j--))
# Append word separator to current word
ref=$2[$j]
-eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
+printf -v $ref %s ${!ref}${COMP_WORDS[i]}
# Indicate new cword
-[ $i = $COMP_CWORD ] eval $3=$j
+[ $i = $COMP_CWORD ] printf -v $3 %s $j
# Indicate next word if available, else end *both* while and
for loop
(( $i ${#COMP_WORDS[@]} - 1)) ((i++)) || break 2
done
# Append word to current word
ref=$2[$j]
-eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
+printf -v $ref %s ${!ref}${COMP_WORDS[i]}
# Indicate new cword
-[[ $i == $COMP_CWORD ]] eval $3=$j
+[[ $i == $COMP_CWORD ]] printf -v $3 %s $j
done
else
# No, list of word completions separators hasn't changed;
-eval $2=\( \\${COMP_WORDS[@]}\ \)
+for i in ${!COMP_WORDS[@]}; do
+printf -v $2[i] %s ${COMP_WORDS[i]}
+done
fi
} # __reassemble_comp_words_by_ref()
@@ -1481,7 +1483,7 @@
COMP_WORDS[i]=${COMP_WORDS[i+$word_offset]}
done
for (( i; i = COMP_CWORD; i++ )); do
-unset COMP_WORDS[i];
+unset 'COMP_WORDS[i]'
done
COMP_CWORD=$(( $COMP_CWORD - $word_offset ))
--
Comment By: Dams Nadé (anvil-guest)
Date: 2014-02-17 14:49
Message:
A better eval-free approach would be to simple do
printf -v $2 %s ${!ref}${COMP_WORDS[i]}
It's faster and more secure this way, imho.
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-02-17 14:45
Message:
Unfortunately __reassemble_comp_words_by_ref is not the only thing affected by
failglob. At least
[Bash-completion-devel] [bash-completion-Bugs][314703] README says to run included configure script, but none is included
bash-completion-Bugs item #314703 was changed at 2014-06-02 13:08 by Ian! D. Allen You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314703group_id=100114 Status: Closed Priority: 3 Submitted By: Ian Kelling (iankelling-guest) Assigned to: Nobody (None) Summary: README says to run included configure script, but none is included Distribution: None Originally reported in: None Milestone: None Status: Invalid Original bug number: Initial Comment: No configure script is included, yet the README file states: If you don't have the package readily available for your distribution, or you simply don't want to use one, you can install bash completion using the standard commands for GNU autotools packages: ./configure make make check # optional, requires dejagnu and tcllib make install # as root -- Comment By: Ian! D. Allen (idallen-guest) Date: 2014-06-02 13:08 Message: Please tell me or point me at documentation on how to install and test the current snapshot, if following the README won't work. I don't speak git much yet, but I see that I can get a lovely tarball snapshot, that I can't install and use because the included documentation is wrong for that kind of tarball. Perhaps you could create a README_GIT_SNAPSHOT to help those of us who are trying to help you test the software? -- Comment By: Ville Skyttä (scop-guest) Date: 2014-06-01 08:38 Message: README documents setup from release tarball, the script is included in it and intentionally not in git. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314703group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314707] shopt -s failglob breaks _parse_help
bash-completion-Bugs item #314707 was changed at 02/06/2014 20:12 by Dams Nadé
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314707group_id=100114
Status: Open
Priority: 3
Submitted By: Ville Skyttä (scop-guest)
Assigned to: Nobody (None)
Summary: shopt -s failglob breaks _parse_help
Distribution: None
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
With shopt -s failglob in test/config/bashrc:
$ ./runUnit _parse_help.exp
[...]
Running ./unit/_parse_help.exp ...
FAIL: long with value and eq sign in brackets
FAIL: long with [no]
FAIL: long with [no-] + optional arg
FAIL: long with [no-] + required arg
FAIL: long with [dont-]
FAIL: short and long with [dont]
FAIL: -f [FOO], --foo[=FOO]
Haven't investigated if this is real breakage or if it's just the test case
that gets broken somehow.
--
Comment By: Dams Nadé (anvil-guest)
Date: 02/06/2014 20:12
Message:
Found an issue, located in __parse_options. One should never do for i in $var
nor for i in $(cmd).
I cant seem to attach any document, so here's the inlined patch :
diff --git a/bash_completion b/bash_completion
index 3e5c813..d61b257 100644
--- a/bash_completion
+++ b/bash_completion
@@ -742,8 +742,10 @@ __parse_options()
# Take first found long option, or first one (short) if not found.
option=
-for i in $1; do
-case $i in
+local -a array
+read -a array $1
+for i in ${array[@]}; do
+case $i in
---*) break ;;
--?*) option=$i ; break ;;
-?*) [[ $option ]] || option=$i ;;
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314707group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314709] -? triggers failglob if left unquoted
bash-completion-Bugs item #314709, was opened at 02/06/2014 21:09 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: -? triggers failglob if left unquoted Distribution: None Originally reported in: None Milestone: 2.0 Status: None Original bug number: Initial Comment: Since '?' is a glob char, it needs to be quoted or an error will be triggered when using failglob. The ssh-add/ssh-keygen completions are broken due to this issue. See attached trivial patch. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314709group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314710] badly-quoted-then-evaled var in _filedir_xspec triggers failglob
bash-completion-Bugs item #314710, was opened at 02/06/2014 23:05 by Dams Nadé You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314710group_id=100114 Status: Open Priority: 3 Submitted By: Dams Nadé (anvil-guest) Assigned to: Nobody (None) Summary: badly-quoted-then-evaled var in _filedir_xspec triggers failglob Distribution: None Originally reported in: None Milestone: 2.0 Status: None Original bug number: Initial Comment: I've managed to fix 7z/vi/acroread test cases with failglob enabled by simply adding a pair of simple quotes in _filedir_xspec. The proper way would be to remove the eval in this line (see attached patch) instead, but my knowledge of the compgen/quote_readline combo is kinda limited. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314710group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314636] psql auto-complete varies depending on .psqlrc contents
bash-completion-Bugs item #314636 was changed at 2014-06-03 03:41 by Igor Murzov You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314636group_id=100114 Status: Closed Priority: 3 Submitted By: Paul Norman (pnorman-guest) Assigned to: Nobody (None) Summary: psql auto-complete varies depending on .psqlrc contents Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: Fix Committed Original bug number: Initial Comment: The psql completions use psql commands such as psql -AtqwlF $'\t' or psql -Atqwc 'select usename from pg_user'. This is an issue when the user has a .psqlrc file which changes the default formatting. A particular problem is \pset format wrapped which changes the output even when -t is in effect. The combination of \pset format wrapped and \pset border 2 will cause | to be the only database suggested, because it's the first character on each line with psql -AtqwlF '\t'. The fix is to pass psql the option -X, which causes it to not load .psqlrc files. -- Comment By: Igor Murzov (garik-guest) Date: 2014-06-03 03:41 Message: Fix commited. Thanks. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314636group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314687] mutt -f =foldernatab loses the '=' prefix
bash-completion-Bugs item #314687, was opened at 2014-05-16 00:04 by Marius Gedminas You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314687group_id=100114 Status: Open Priority: 3 Submitted By: Marius Gedminas (mgedmin-guest) Assigned to: Nobody (None) Summary: mutt -f =foldernatab loses the '=' prefix Distribution: Ubuntu Originally reported in: Ubuntu Launchpad Milestone: None Status: None Original bug number: 1008380 Initial Comment: 1. Type 'mutt -f =sent' and press tab Expected completion: 'mutt -f =sent-mail' Actual completion: 'mutt -f sent-mail' The same problem exists for 'mutt -f +senttab' I'm attaching a patch that fixes this -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314687group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314501] PATH: pypy support
bash-completion-Bugs item #314501 was changed at 2014-05-14 01:03 by Igor Murzov You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314501group_id=100114 Status: Closed Priority: 3 Submitted By: Stefano Rivera (stefanor) Assigned to: Nobody (None) Summary: PATH: pypy support Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: Fix Committed Original bug number: Initial Comment: Here's a simple patch to extend the python completion, to support pypy. pypy is a drop-in replacement for cPython, so the argument parsing is identical. -- Comment By: Igor Murzov (garik-guest) Date: 2014-05-14 01:03 Message: The patch has been commited: https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=bash-completion/bash-completion.git;a=commit;h=38a013e22cd30c0cce84caaaff2763d0c39ce131 Thanks. -- Comment By: Stefano Rivera (stefanor) Date: 2013-10-24 16:10 Message: err s/PATH/PATCH/ -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314501group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314673] Please add host completion to 'host' and 'nslookup'
bash-completion-Bugs item #314673, was opened at 2014-05-01 11:25 by Dan Wallis You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314673group_id=100114 Status: Open Priority: 3 Submitted By: Dan Wallis (fredden-guest) Assigned to: Nobody (None) Summary: Please add host completion to 'host' and 'nslookup' Distribution: Debian Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: It's frustrated me for a while now that 'host' doesn't complete like 'ping' and 'dig' and 'ssh' do. The following patch fixes that. Please can this be included in Jessie? fredden@gordo:/usr/share/bash-completion/completions$ ls -lh host nslookup lrwxrwxrwx 1 root root8 Jun 18 2012 host - nslookup -rw-r--r-- 1 root root 1.9K May 1 11:13 nslookup fredden@gordo:/usr/share/bash-completion/completions$ diff -u nslookup-orig nslookup --- nslookup-orig 2014-05-01 11:12:29.0 +1200 +++ nslookup2014-05-01 11:13:00.0 +1200 @@ -40,6 +40,8 @@ -retry= -timeout= -vc -novc -fail -nofail' -- $cur ) ) [[ $COMPREPLY == *= ]] compopt -o nospace fi + +_known_hosts_real $cur } complete -F _nslookup nslookup @@ -69,6 +71,8 @@ if [[ $cur == -* ]]; then COMPREPLY=( $( compgen -W '$( _parse_usage $1 )' -- $cur ) ) fi + +_known_hosts_real $cur } complete -F _host host fredden@gordo:/usr/share/bash-completion/completions$ dpkg-query -S nslookup | grep bash-completion bash-completion: /usr/share/bash-completion/completions/nslookup fredden@gordo:/usr/share/bash-completion/completions$ apt-cache show bash-completion | head -n 2 Package: bash-completion Version: 1:2.0-1 fredden@gordo:/usr/share/bash-completion/completions$ -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314673group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314673] Please add host completion to 'host' and 'nslookup'
bash-completion-Bugs item #314673 was changed at 2014-05-01 11:34 by Dan Wallis You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314673group_id=100114 Status: Open Priority: 3 Submitted By: Dan Wallis (fredden-guest) Assigned to: Nobody (None) Summary: Please add host completion to 'host' and 'nslookup' Distribution: Debian Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: It's frustrated me for a while now that 'host' doesn't complete like 'ping' and 'dig' and 'ssh' do. The following patch fixes that. Please can this be included in Jessie? fredden@gordo:/usr/share/bash-completion/completions$ ls -lh host nslookup lrwxrwxrwx 1 root root8 Jun 18 2012 host - nslookup -rw-r--r-- 1 root root 1.9K May 1 11:13 nslookup fredden@gordo:/usr/share/bash-completion/completions$ diff -u nslookup-orig nslookup --- nslookup-orig 2014-05-01 11:12:29.0 +1200 +++ nslookup2014-05-01 11:13:00.0 +1200 @@ -40,6 +40,8 @@ -retry= -timeout= -vc -novc -fail -nofail' -- $cur ) ) [[ $COMPREPLY == *= ]] compopt -o nospace fi + +_known_hosts_real $cur } complete -F _nslookup nslookup @@ -69,6 +71,8 @@ if [[ $cur == -* ]]; then COMPREPLY=( $( compgen -W '$( _parse_usage $1 )' -- $cur ) ) fi + +_known_hosts_real $cur } complete -F _host host fredden@gordo:/usr/share/bash-completion/completions$ dpkg-query -S nslookup | grep bash-completion bash-completion: /usr/share/bash-completion/completions/nslookup fredden@gordo:/usr/share/bash-completion/completions$ apt-cache show bash-completion | head -n 2 Package: bash-completion Version: 1:2.0-1 fredden@gordo:/usr/share/bash-completion/completions$ -- Comment By: Dan Wallis (fredden-guest) Date: 2014-05-01 11:34 Message: Have just found that git HEAD already includes this line in the _host function. I've also checked and that version is in Jessie. Please close this request as FIXED. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314673group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314667] unexpected EOF when completing inside $(...)
bash-completion-Bugs item #314667 was changed at 2014-04-29 01:17 by Mara Kim You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314667group_id=100114 Status: Open Priority: 3 Submitted By: Jay Foad (jayfoad-guest) Assigned to: Nobody (None) Summary: unexpected EOF when completing inside $(...) Distribution: Ubuntu Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: When I try to tab-complete here: $ ls $(which lsTAB I get these error messages: bash: unexpected EOF while looking for matching `)' bash: syntax error: unexpected end of file I'm using packages bash 4.3-6ubuntu1 and bash-completion 1:2.1-4 on Ubuntu 14.04. -- Comment By: Mara Kim (mara-guest) Date: 2014-04-29 01:17 Message: Also reported in the Debain bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742466 I have attached the output of `bash +x` when you type: echo $(which bTAB System info: GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu), AKA 4.3-7ubuntu Ubuntu 14.04 LTS bash-completion 1:2.1-4 Linux 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux New since Ubuntu 13.10 which used bash 4.2-5ubuntu, bash-completion 1.2.0-1ubuntu -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314667group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314667] unexpected EOF when completing inside $(...)
bash-completion-Bugs item #314667 was changed at 2014-04-29 01:19 by Mara Kim
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314667group_id=100114
Status: Open
Priority: 3
Submitted By: Jay Foad (jayfoad-guest)
Assigned to: Nobody (None)
Summary: unexpected EOF when completing inside $(...)
Distribution: Ubuntu
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
When I try to tab-complete here:
$ ls $(which lsTAB
I get these error messages:
bash: unexpected EOF while looking for matching `)'
bash: syntax error: unexpected end of file
I'm using packages bash 4.3-6ubuntu1 and bash-completion 1:2.1-4 on Ubuntu
14.04.
--
Comment By: Mara Kim (mara-guest)
Date: 2014-04-29 01:19
Message:
Unable to attach the file, so here is a dump
BEGIN EXECUTION TRACE
$ echo $(which b+ local compfile=./completions
+ [[ /usr/share/bash-completion/bash_completion == */* ]]
+ compfile=/usr/share/bash-completion/completions
+ compfile+=/echo
+ [[ -f /usr/share/bash-completion/completions/echo ]]
+ complete -F _minimal echo
+ return 124
+ local cur prev words cword split
+ _init_completion -s
+ local exclude= flag outx errx inx OPTIND=1
+ getopts n:e:o:i:s flag -s
+ case $flag in
+ split=false
+ exclude+==
+ getopts n:e:o:i:s flag -s
+ COMPREPLY=()
+ local 'redir=@(?([0-9])|?([0-9])?()|)'
+ _get_comp_words_by_ref -n '=' cur prev words cword
+ local exclude flag i OPTIND=1
+ words=()
+ local cur cword words
+ upargs=()
+ upvars=()
+ local upargs upvars vcur vcword vprev vwords
+ getopts c:i:n:p:w: flag -n '=' cur prev words cword
+ case $flag in
+ exclude='='
+ getopts c:i:n:p:w: flag -n '=' cur prev words cword
+ [[ 6 -ge 3 ]]
+ case ${!OPTIND} in
+ vcur=cur
+ let 'OPTIND += 1'
+ [[ 6 -ge 4 ]]
+ case ${!OPTIND} in
+ vprev=prev
+ let 'OPTIND += 1'
+ [[ 6 -ge 5 ]]
+ case ${!OPTIND} in
+ vwords=words
+ let 'OPTIND += 1'
+ [[ 6 -ge 6 ]]
+ case ${!OPTIND} in
+ vcword=cword
+ let 'OPTIND += 1'
+ [[ 6 -ge 7 ]]
+ __get_cword_at_cursor_by_ref '=' words cword cur
+ words=()
+ local cword words
+ __reassemble_comp_words_by_ref '=' words cword
+ local exclude i j line ref
+ [[ -n = ]]
+ exclude='='
+ eval cword=1
++ cword=1
+ [[ -n = ]]
+ line='echo $(which b'
+ (( i=0, j=0 ))
+ (( i 2 ))
+ [[ 0 -gt 0 ]]
+ ref='words[0]'
+ eval 'words[0]=${!ref}${COMP_WORDS[i]}'
++ words[0]=echo
+ line=' $(which b'
+ [[ 0 == 1 ]]
+ (( i++, j++ ))
+ (( i 2 ))
+ [[ 1 -gt 0 ]]
+ [[ $(which b == +([=]) ]]
+ ref='words[1]'
+ eval 'words[1]=${!ref}${COMP_WORDS[i]}'
++ words[1]='$(which b'
+ line=
+ [[ 1 == 1 ]]
+ eval cword=1
++ cword=1
+ (( i++, j++ ))
+ (( i 2 ))
+ [[ 2 == 1 ]]
+ local i cur index=14 'lead=echo $(which b'
+ [[ 14 -gt 0 ]]
+ [[ -n echo $(which b ]]
+ [[ -n echo$(whichb ]]
+ cur='echo $(which b'
+ (( i = 0 ))
+ (( i = cword ))
+ [[ 14 -ge 4 ]]
+ [[ echo != \e\c\h\o ]]
+ [[ 0 -lt 1 ]]
+ local old_size=14
+ cur=' $(which b'
+ local new_size=10
+ index=10
+ (( ++i ))
+ (( i = cword ))
+ [[ 10 -ge 9 ]]
+ [[ $(which != \$\(\w\h\i\c\h\ \b ]]
+ cur='$(which b'
+ (( index-- ))
+ [[ 9 -ge 9 ]]
+ [[ $(which b != \$\(\w\h\i\c\h\ \b ]]
+ [[ 1 -lt 1 ]]
+ (( ++i ))
+ (( i = cword ))
+ [[ -n $(which b ]]
+ [[ ! -n $(whichb ]]
+ [[ 9 -lt 0 ]]
+ local words cword cur
+ _upvars -a2 words echo '$(which b' -v cword 1 -v cur '$(which b'
+ (( 10 ))
+ (( 10 ))
+ case $1 in
+ [[ -n 2 ]]
+ printf %d 2
+ [[ -n words ]]
+ unset -v words
+ eval 'words=(${@:3:2})'
++ words=(${@:3:2})
+ shift 4
+ (( 6 ))
+ case $1 in
+ [[ -n cword ]]
+ unset -v cword
+ eval 'cword=$3'
++ cword=1
+ shift 3
+ (( 3 ))
+ case $1 in
+ [[ -n cur ]]
+ unset -v cur
+ eval 'cur=$3'
++ cur='$(which b'
+ shift 3
+ (( 0 ))
+ [[ -n cur ]]
+ upvars+=($vcur)
+ upargs+=(-v $vcur $cur)
+ [[ -n cword ]]
+ upvars+=($vcword)
+ upargs+=(-v $vcword $cword)
+ [[ -n prev ]]
+ [[ 1 -ge 1 ]]
+ upvars+=($vprev)
+ upargs+=(-v $vprev ${words[cword - 1]})
+ [[ -n words ]]
+ upvars+=($vwords)
+ upargs+=(-a${#words[@]} $vwords ${words[@]})
+ (( 4 ))
+ local cur cword prev words
+ _upvars -v cur '$(which b' -v cword 1 -v prev echo -a2 words echo '$(which b'
+ (( 13 ))
+ (( 13 ))
+ case $1 in
+ [[ -n cur ]]
+ unset -v cur
+ eval 'cur=$3'
++ cur='$(which b'
+ shift 3
+ (( 10 ))
+ case $1 in
+ [[ -n cword ]]
+ unset -v cword
+ eval 'cword=$3'
++ cword=1
+ shift 3
+ (( 7 ))
+ case $1 in
+ [[ -n prev ]]
+ unset -v prev
+ eval 'prev=$3'
++ prev=echo
+ shift 3
+ (( 4 ))
+ case $1 in
+ [[ -n 2 ]]
+ printf %d 2
+ [[ -n words ]]
+ unset -v words
+ eval 'words=(${@:3:2})'
++ words=(${@:3:2})
+ shift 4
+ (( 0 ))
+ _variables
+ [[ $(which b =~ ^(\$\{?)([A-Za-z0-9_]*)$ ]]
+ return 1
+ [[ $(which b == @(?([0-9])|?([0-9])?()|)* ]]
+ [[ echo == @(?([0-9])|?([0-9])?()|) ]]
+ local i skip
+ (( i=1 ))
+ (( i 2 ))
+ [[ $(which b == @(?([0-9])|?([0-9])?()|)* ]]
+ i=2
+ (( 1 ))
+ (( i 2 ))
+ [[ 1 -le 0 ]]
+ prev=echo
+ [[ -n false ]]
+ _split_longopt
[Bash-completion-devel] [bash-completion-Bugs][314667] unexpected EOF when completing inside $(...)
bash-completion-Bugs item #314667, was opened at 2014-04-23 11:50 by Jay Foad You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314667group_id=100114 Status: Open Priority: 3 Submitted By: Jay Foad (jayfoad-guest) Assigned to: Nobody (None) Summary: unexpected EOF when completing inside $(...) Distribution: Ubuntu Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: When I try to tab-complete here: $ ls $(which lsTAB I get these error messages: bash: unexpected EOF while looking for matching `)' bash: syntax error: unexpected end of file I'm using packages bash 4.3-6ubuntu1 and bash-completion 1:2.1-4 on Ubuntu 14.04. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314667group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314664] [PATCH] gdb: support --args style completion
bash-completion-Bugs item #314664, was opened at 2014-04-22 17:00 by Peter Wu You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314664group_id=100114 Status: Open Priority: 3 Submitted By: Peter Wu (lekensteyn-guest) Assigned to: Nobody (None) Summary: [PATCH] gdb: support --args style completion Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: This patch adds support for completing `gdb --args program [program args]`. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314664group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314656] Completion after perl -l does not complete filenames.
bash-completion-Bugs item #314656 was changed at 2014-04-16 11:54 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314656group_id=100114 Status: Open Priority: 3 Submitted By: Shlomi Fish (shlomif-guest) Assigned to: Nobody (None) Summary: Completion after perl -l does not complete filenames. Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: I'm on Mageia Linux 5 Cauldron using bash-completion-2.1-6.mga5 and after I do this: shlomif@telaviv1:~$ echo $'#!/usr/bin/perl\nprint Hello\\n;' myperl.pl shlomif@telaviv1:~$ perl -l m[tab] The [tab] does not complete. perl -l [tab] does not complete either. OTOH doing: shlomif@telaviv1:~$ perl -l myperl.pl Hello shlomif@telaviv1:~$ Works fine. Please look into fixing it. -- Comment By: Ville Skyttä (scop-guest) Date: 2014-04-16 11:54 Message: See one reply on list: http://lists.alioth.debian.org/pipermail/bash-completion-devel/2014-April/005318.html What Pavel's response doesn't take into account is that the argument to -l is optional. I don't think we can cover this very well -- either we insist that an argument is given (which is what we currently do), or insist that it's not. Both are incorrect, it's a matter of picking the lesser evil. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314656group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314652] [patch] add support for the new apt command
bash-completion-Bugs item #314652, was opened at 2014-04-14 07:53 by Michael Vogt You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314652group_id=100114 Status: Open Priority: 3 Submitted By: Michael Vogt (mvo) Assigned to: Nobody (None) Summary: [patch] add support for the new apt command Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Attached is a bash completion file for the new apt binary found in debian and ubuntu. It is slightly different than the existing apt-get/apt-cache completions in that it tries to present only --options that are specific to the commands. Feedback very welcome! Thanks, Michael -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314652group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314639] [patch] man completion, portability fix
bash-completion-Bugs item #314639, was opened at 02/04/2014 08:52 by Matthieu Crapet You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314639group_id=100114 Status: Open Priority: 3 Submitted By: Matthieu Crapet (mcrapet-guest) Assigned to: Nobody (None) Summary: [patch] man completion, portability fix Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: 2.0 Status: None Original bug number: Initial Comment: Hi, See attached patch for the small fix! Regards, Matthieu -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314639group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314639] [patch] man completion, portability fix
bash-completion-Bugs item #314639 was changed at 2014-04-02 12:03 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314639group_id=100114 Status: Closed Priority: 3 Submitted By: Matthieu Crapet (mcrapet-guest) Assigned to: Nobody (None) Summary: [patch] man completion, portability fix Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: 2.0 Status: Fix Committed Original bug number: Initial Comment: Hi, See attached patch for the small fix! Regards, Matthieu -- Comment By: Ville Skyttä (scop-guest) Date: 2014-04-02 12:03 Message: Applied, thanks. http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=4927730 -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314639group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314636] psql auto-complete varies depending on .psqlrc contents
bash-completion-Bugs item #314636, was opened at 2014-03-26 00:16 by Paul Norman You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314636group_id=100114 Status: Open Priority: 3 Submitted By: Paul Norman (pnorman-guest) Assigned to: Nobody (None) Summary: psql auto-complete varies depending on .psqlrc contents Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: The psql completions use psql commands such as psql -AtqwlF $'\t' or psql -Atqwc 'select usename from pg_user'. This is an issue when the user has a .psqlrc file which changes the default formatting. A particular problem is \pset format wrapped which changes the output even when -t is in effect. The combination of \pset format wrapped and \pset border 2 will cause | to be the only database suggested, because it's the first character on each line with psql -AtqwlF '\t'. The fix is to pass psql the option -X, which causes it to not load .psqlrc files. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314636group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314630] Processus names completion: fixme for processus module names
bash-completion-Bugs item #314630, was opened at 2014-03-18 23:33 by Samuel BAUER You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314630group_id=100114 Status: Open Priority: 3 Submitted By: Samuel BAUER (mazes_80-guest) Assigned to: Nobody (None) Summary: Processus names completion: fixme for processus module names Distribution: Gentoo Originally reported in: Debian BTS Milestone: None Status: None Original bug number: Initial Comment: # FIXME: completes [kblockd/0] to 0. Previously it was completed # to kblockd which isn't correct either. kblockd/0 would be # arguably most correct, but killall from psmisc 22 treats arguments # containing / specially unless -r is given so that wouldn't quite # work either. Perhaps it'd be best to not complete these to anything # for now. In bash_completion script, doesn't point to any opened bug, sorry if there's already one. The attached patch replace s:.*/:: by /^[^[]/s:.*/:: Who won't match modules, and output desired kblockd/0 I only tested it with bash-completion-1.3 (current stable in gentoo). Hope being helpful. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314630group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][312741] shopt -s failglob breaks __reassemble_comp_words_by_ref
bash-completion-Bugs item #312741 was changed at 2014-02-17 10:57 by Isaac
Jurado
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=312741group_id=100114
Status: Open
Priority: 3
Submitted By: Ville Skyttä (scop-guest)
Assigned to: Nobody (None)
Summary: shopt -s failglob breaks __reassemble_comp_words_by_ref
Distribution: None
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
$ shopt -s failglob
$ ssh TABbash: no match: words[0]=${!ref}${COMP_WORDS[i]}
http://thread.gmane.org/gmane.comp.shells.bash.completion.devel/2546
--
Comment By: Isaac Jurado (etanol-guest)
Date: 2014-02-17 10:57
Message:
I found this issue too (using 2.0 from Ubuntu Saucy). There is actually a very
simple fix that allows you to have failglob enabled with bash_completion
included too.
The trick is to temporarily disable failglob while executing the
__reassemble_comp_words_by_ref and then restoring it, in case it was disabled:
--- /usr/share/bash-completion/bash_completion.orig 2014-02-17
11:44:05.879501602 +0100
+++ /usr/share/bash-completion/bash_completion 2014-02-17 11:42:25.967499666
+0100
@@ -237,7 +237,10 @@
#
__reassemble_comp_words_by_ref()
{
-local exclude i j line ref
+local exclude i j line ref fgr
+shopt -pq failglob
+fgr=$?
+shopt -u failglob
# Exclude word separator characters?
if [[ $1 ]]; then
# Yes, exclude word separator characters;
@@ -288,6 +291,7 @@
# No, list of word completions separators hasn't changed;
eval $2=\( \\${COMP_WORDS[@]}\ \)
fi
+(( $fgr )) || shopt -s failglob
} # __reassemble_comp_words_by_ref()
--
Comment By: Ian! D. Allen (idallen-guest)
Date: 2013-08-30 22:28
Message:
In addition to failures under set -u, using shopt -s failglob also
causes errors that make all bash_completion versions (including 2.1)
unusable:
$ env -i bash --login --noprofile --norc
bash-4.2$ shopt -s failglob
bash-4.2$ . /usr/share/bash-completion/bash_completion
bash-4.2$ make TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ find TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ mutt TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ date TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ echo TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
etc.
The code has many errors where characters are not quoted (e.g. bash
array subscripts), so they try to expand as GLOB file names and fail.
As an example, to fix the above, change the lines:
eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
to this:
eval $ref='${!ref-}${COMP_WORDS[i]-}'
everywhere (and also fix it so that set -u doesn't also make it fail).
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=312741group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][312741] shopt -s failglob breaks __reassemble_comp_words_by_ref
bash-completion-Bugs item #312741 was changed at 2014-02-17 14:45 by Ville
Skyttä
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=312741group_id=100114
Status: Open
Priority: 3
Submitted By: Ville Skyttä (scop-guest)
Assigned to: Nobody (None)
Summary: shopt -s failglob breaks __reassemble_comp_words_by_ref
Distribution: None
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
$ shopt -s failglob
$ ssh TABbash: no match: words[0]=${!ref}${COMP_WORDS[i]}
http://thread.gmane.org/gmane.comp.shells.bash.completion.devel/2546
--
Comment By: Ville Skyttä (scop-guest)
Date: 2014-02-17 14:45
Message:
Unfortunately __reassemble_comp_words_by_ref is not the only thing affected by
failglob. At least all _install_xspec ones and ipmitool are, and I don't know
of a good recipe how to detect/grep an exhaustive list.
One approach for better-than-nothing coverage is to set shopt -s failglob in
our test suite's test/config/bashrc and start working on the failures it causes
there.
--
Comment By: Isaac Jurado (etanol-guest)
Date: 2014-02-17 12:57
Message:
I found this issue too (using 2.0 from Ubuntu Saucy). There is actually a very
simple fix that allows you to have failglob enabled with bash_completion
included too.
The trick is to temporarily disable failglob while executing the
__reassemble_comp_words_by_ref and then restoring it, in case it was disabled:
--- /usr/share/bash-completion/bash_completion.orig 2014-02-17
11:44:05.879501602 +0100
+++ /usr/share/bash-completion/bash_completion 2014-02-17 11:42:25.967499666
+0100
@@ -237,7 +237,10 @@
#
__reassemble_comp_words_by_ref()
{
-local exclude i j line ref
+local exclude i j line ref fgr
+shopt -pq failglob
+fgr=$?
+shopt -u failglob
# Exclude word separator characters?
if [[ $1 ]]; then
# Yes, exclude word separator characters;
@@ -288,6 +291,7 @@
# No, list of word completions separators hasn't changed;
eval $2=\( \\${COMP_WORDS[@]}\ \)
fi
+(( $fgr )) || shopt -s failglob
} # __reassemble_comp_words_by_ref()
--
Comment By: Ian! D. Allen (idallen-guest)
Date: 2013-08-31 01:28
Message:
In addition to failures under set -u, using shopt -s failglob also
causes errors that make all bash_completion versions (including 2.1)
unusable:
$ env -i bash --login --noprofile --norc
bash-4.2$ shopt -s failglob
bash-4.2$ . /usr/share/bash-completion/bash_completion
bash-4.2$ make TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ find TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ mutt TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ date TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ echo TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
etc.
The code has many errors where characters are not quoted (e.g. bash
array subscripts), so they try to expand as GLOB file names and fail.
As an example, to fix the above, change the lines:
eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
to this:
eval $ref='${!ref-}${COMP_WORDS[i]-}'
everywhere (and also fix it so that set -u doesn't also make it fail).
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=312741group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][312741] shopt -s failglob breaks __reassemble_comp_words_by_ref
bash-completion-Bugs item #312741 was changed at 17/02/2014 13:49 by Dams Nadé
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=312741group_id=100114
Status: Open
Priority: 3
Submitted By: Ville Skyttä (scop-guest)
Assigned to: Nobody (None)
Summary: shopt -s failglob breaks __reassemble_comp_words_by_ref
Distribution: None
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
$ shopt -s failglob
$ ssh TABbash: no match: words[0]=${!ref}${COMP_WORDS[i]}
http://thread.gmane.org/gmane.comp.shells.bash.completion.devel/2546
--
Comment By: Dams Nadé (anvil-guest)
Date: 17/02/2014 13:49
Message:
A better eval-free approach would be to simple do
printf -v $2 %s ${!ref}${COMP_WORDS[i]}
It's faster and more secure this way, imho.
--
Comment By: Ville Skyttä (scop-guest)
Date: 17/02/2014 13:45
Message:
Unfortunately __reassemble_comp_words_by_ref is not the only thing affected by
failglob. At least all _install_xspec ones and ipmitool are, and I don't know
of a good recipe how to detect/grep an exhaustive list.
One approach for better-than-nothing coverage is to set shopt -s failglob in
our test suite's test/config/bashrc and start working on the failures it causes
there.
--
Comment By: Isaac Jurado (etanol-guest)
Date: 17/02/2014 11:57
Message:
I found this issue too (using 2.0 from Ubuntu Saucy). There is actually a very
simple fix that allows you to have failglob enabled with bash_completion
included too.
The trick is to temporarily disable failglob while executing the
__reassemble_comp_words_by_ref and then restoring it, in case it was disabled:
--- /usr/share/bash-completion/bash_completion.orig 2014-02-17
11:44:05.879501602 +0100
+++ /usr/share/bash-completion/bash_completion 2014-02-17 11:42:25.967499666
+0100
@@ -237,7 +237,10 @@
#
__reassemble_comp_words_by_ref()
{
-local exclude i j line ref
+local exclude i j line ref fgr
+shopt -pq failglob
+fgr=$?
+shopt -u failglob
# Exclude word separator characters?
if [[ $1 ]]; then
# Yes, exclude word separator characters;
@@ -288,6 +291,7 @@
# No, list of word completions separators hasn't changed;
eval $2=\( \\${COMP_WORDS[@]}\ \)
fi
+(( $fgr )) || shopt -s failglob
} # __reassemble_comp_words_by_ref()
--
Comment By: Ian! D. Allen (idallen-guest)
Date: 31/08/2013 00:28
Message:
In addition to failures under set -u, using shopt -s failglob also
causes errors that make all bash_completion versions (including 2.1)
unusable:
$ env -i bash --login --noprofile --norc
bash-4.2$ shopt -s failglob
bash-4.2$ . /usr/share/bash-completion/bash_completion
bash-4.2$ make TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ find TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ mutt TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ date TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
bash-4.2$ echo TAB bash: no match: words[0]=${!ref}${COMP_WORDS[i]}
etc.
The code has many errors where characters are not quoted (e.g. bash
array subscripts), so they try to expand as GLOB file names and fail.
As an example, to fix the above, change the lines:
eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
to this:
eval $ref='${!ref-}${COMP_WORDS[i]-}'
everywhere (and also fix it so that set -u doesn't also make it fail).
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=312741group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][312741] shopt -s failglob breaks __reassemble_comp_words_by_ref
bash-completion-Bugs item #312741 was changed at 17/02/2014 14:03 by Dams Nadé
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=312741group_id=100114
Status: Open
Priority: 3
Submitted By: Ville Skyttä (scop-guest)
Assigned to: Nobody (None)
Summary: shopt -s failglob breaks __reassemble_comp_words_by_ref
Distribution: None
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
$ shopt -s failglob
$ ssh TABbash: no match: words[0]=${!ref}${COMP_WORDS[i]}
http://thread.gmane.org/gmane.comp.shells.bash.completion.devel/2546
--
Comment By: Dams Nadé (anvil-guest)
Date: 17/02/2014 14:03
Message:
I got this patch, here to solve this issue i think :
diff -u --exclude CVS --exclude .svn --exclude .bzr --exclude .pc --exclude
test --exclude completions --exclude debian -ub
bash-completion-1.3.orig/bash_completion bash-completion-1.3/bash_completion
--- bash-completion-1.3.orig/bash_completion2013-09-12 16:06:45.0
+0200
+++ bash-completion-1.3/bash_completion 2013-09-12 17:25:19.0 +0200
@@ -286,7 +286,7 @@
fi
# Default to cword unchanged
-eval $3=$COMP_CWORD
+printf -v $3 %s $COMP_CWORD
# Are characters excluded which were former included?
if [[ $exclude ]]; then
# Yes, list of word completion separators has shrunk;
@@ -296,26 +296,28 @@
# empty and is word made up of just word separator characters to be
# excluded?
while [[ $i -gt 0 ${COMP_WORDS[$i]}
-${COMP_WORDS[$i]//[^$exclude]} == ${COMP_WORDS[$i]}
+${COMP_WORDS[$i]//[^$exclude]} = ${COMP_WORDS[$i]}
]]; do
[ $j -ge 2 ] ((j--))
# Append word separator to current word
ref=$2[$j]
-eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
+printf -v $ref %s ${!ref}${COMP_WORDS[i]}
# Indicate new cword
-[ $i = $COMP_CWORD ] eval $3=$j
+[ $i = $COMP_CWORD ] printf -v $3 %s $j
# Indicate next word if available, else end *both* while and
for loop
(( $i ${#COMP_WORDS[@]} - 1)) ((i++)) || break 2
done
# Append word to current word
ref=$2[$j]
-eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
+printf -v $ref %s ${!ref}${COMP_WORDS[i]}
# Indicate new cword
-[[ $i == $COMP_CWORD ]] eval $3=$j
+[[ $i == $COMP_CWORD ]] printf -v $3 %s $j
done
else
# No, list of word completions separators hasn't changed;
-eval $2=\( \\${COMP_WORDS[@]}\ \)
+for i in ${!COMP_WORDS[@]}; do
+printf -v $2[i] %s ${COMP_WORDS[i]}
+done
fi
} # __reassemble_comp_words_by_ref()
@@ -1481,7 +1483,7 @@
COMP_WORDS[i]=${COMP_WORDS[i+$word_offset]}
done
for (( i; i = COMP_CWORD; i++ )); do
-unset COMP_WORDS[i];
+unset 'COMP_WORDS[i]'
done
COMP_CWORD=$(( $COMP_CWORD - $word_offset ))
--
Comment By: Dams Nadé (anvil-guest)
Date: 17/02/2014 13:49
Message:
A better eval-free approach would be to simple do
printf -v $2 %s ${!ref}${COMP_WORDS[i]}
It's faster and more secure this way, imho.
--
Comment By: Ville Skyttä (scop-guest)
Date: 17/02/2014 13:45
Message:
Unfortunately __reassemble_comp_words_by_ref is not the only thing affected by
failglob. At least all _install_xspec ones and ipmitool are, and I don't know
of a good recipe how to detect/grep an exhaustive list.
One approach for better-than-nothing coverage is to set shopt -s failglob in
our test suite's test/config/bashrc and start working on the failures it causes
there.
--
Comment By: Isaac Jurado (etanol-guest)
Date: 17/02/2014 11:57
Message:
I found this issue too (using 2.0 from Ubuntu Saucy). There is actually a very
simple fix that allows you to have failglob enabled with bash_completion
included too.
The trick is to temporarily disable failglob while executing the
__reassemble_comp_words_by_ref and then restoring it, in case it was disabled:
--- /usr/share/bash-completion/bash_completion.orig 2014-02-17
11:44:05.879501602 +0100
+++ /usr/share/bash-completion/bash_completion 2014-02-17 11:42:25.967499666
+0100
@@ -237,7 +237,10 @@
#
__reassemble_comp_words_by_ref()
{
-local exclude i j line ref
+local exclude i j line ref fgr
+shopt -pq failglob
+fgr=$?
+shopt -u failglob
# Exclude word separator characters?
if [[ $1 ]]; then
# Yes, exclude word separator characters;
@@ -288,6 +291,7 @@
# No, list
[Bash-completion-devel] [bash-completion-Bugs][314592] Strange autocompletion behavior when use ' (apostroph) in PATH variable
bash-completion-Bugs item #314592 was changed at 2014-02-08 14:01 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314592group_id=100114 Status: Closed Priority: 3 Submitted By: Nikita Ilyushkin (ilyushkeane-guest) Assigned to: Nobody (None) Summary: Strange autocompletion behavior when use ' (apostroph) in PATH variable Distribution: Debian Originally reported in: None Milestone: None Status: Invalid Original bug number: Initial Comment: http://askubuntu.com/questions/415043/strange-autocompletion-behavior Situation: expanding PATH variable influence word completion, based on whether was apostrophes in additional path or not. Example: I have an exe file (called deadbeef) with appropriate exe rights, which path contains 2 apostrophes: /home/mallniya/hard'n'soft/soft/gnu-linux/portable/deadbeef-0.6.0 Specialy for an experiment I put the same file to the /home/mallniya/hardnsoftaa/soft/gnu-linux/portable/deadbeef-0.6.0 If I export first path to the variable $PATH there will be no autocompletion in bash, but will be in a second case. Example: When I type in terminal first letters of program, which resides in exported directory, and then use TAB for completion : dead [TAB] there is no completion in first case, but when I use TAB with the same word in second condition - it works. Moreover, both which and type commands tells, that exe file is existed in both case. So if I type command deadbeef in first case manually - it also executes. So what's the problem? -- Comment By: Ville Skyttä (scop-guest) Date: 2014-02-08 14:01 Message: Seems that we (bash-completion) have nothing to do with this; plain vanilla bash behaves as described. See BUG REPORTS in the bash man page if you wish to report it against bash. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314592group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314592] Strange autocompletion behavior when use ' (apostroph) in PATH variable
bash-completion-Bugs item #314592, was opened at 2014-02-04 11:44 by Nikita Ilyushkin You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314592group_id=100114 Status: Open Priority: 3 Submitted By: Nikita Ilyushkin (ilyushkeane-guest) Assigned to: Nobody (None) Summary: Strange autocompletion behavior when use ' (apostroph) in PATH variable Distribution: Debian Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: http://askubuntu.com/questions/415043/strange-autocompletion-behavior Situation: expanding PATH variable influence word completion, based on whether was apostrophes in additional path or not. Example: I have an exe file (called deadbeef) with appropriate exe rights, which path contains 2 apostrophes: /home/mallniya/hard'n'soft/soft/gnu-linux/portable/deadbeef-0.6.0 Specialy for an experiment I put the same file to the /home/mallniya/hardnsoftaa/soft/gnu-linux/portable/deadbeef-0.6.0 If I export first path to the variable $PATH there will be no autocompletion in bash, but will be in a second case. Example: When I type in terminal first letters of program, which resides in exported directory, and then use TAB for completion : dead [TAB] there is no completion in first case, but when I use TAB with the same word in second condition - it works. Moreover, both which and type commands tells, that exe file is existed in both case. So if I type command deadbeef in first case manually - it also executes. So what's the problem? -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314592group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314549] Programmable completions based on file extension introduce regression
bash-completion-Bugs item #314549, was opened at 17/12/2013 14:29 by Sebastien Bardeau You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314549group_id=100114 Status: Open Priority: 3 Submitted By: Sebastien Bardeau (bardeau-guest) Assigned to: Nobody (None) Summary: Programmable completions based on file extension introduce regression Distribution: Fedora / Red Hat Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Dear all, I hope this is the right place to report this problem. I am a Fedora 19 user with bash 4.2.45(1)-release installed. It seems that the new bash programmable completions are being distributed and enabled by default on several systems since a few months now. This raises several problems, the most critical one being that some completions are now based on a list of extensions associated to each program. Here are 3 examples which I encoutered and finally decided me to make this report: 1) say I have a PDF file named myfile.pdf-saved: this file name won't tab-complete with my favorite PDF reader. 2) say I have a PDF file named myfile (no extension): this file name won't tab-complete with my favorite PDF reader. 3) say I have a file named myfile.avi: this file name won't tab-complete with my favorite text editor (I often create companion ascii files to my avi files: I just type vi myfile.avi with the help of the completion -names are often cumbersome-, and then just rename the extension). In other words, the current default breaks tab-completions of files: 1) with unexpected file extensions regarding its content, 2) with no file extension at all, 3) with unsupported file content. By break I mean that there is no completion at all, and no related warning issued to the user. Given the fact that the standard bash behavior is to provide completion for all files when using TAB, this new behavior is at least a regression, if not a bug. The M-/ combination was introduced to retrieve the old behavior, but still: TAB is broken. The key of the problem is not the programmable completion, it is that the completion based on file extension 1) is enabled by default (opt-out) 2) to some predefined defaults. On the other hand I think there is no problem with the other rules (e.g. completing command keywords is a nice feature), since they do not seem to break anything. So, is there any hope to make the programmable completions based on file extension as NOT the default? For example making them opt-in, or enable them using a special key combination like M-/ Thanks. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314549group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314549] Programmable completions based on file extension introduce regression
bash-completion-Bugs item #314549 was changed at 2013-12-17 19:21 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314549group_id=100114 Status: Closed Priority: 3 Submitted By: Sebastien Bardeau (bardeau-guest) Assigned to: Nobody (None) Summary: Programmable completions based on file extension introduce regression Distribution: Fedora / Red Hat Originally reported in: None Milestone: None Status: Won't Fix Original bug number: Initial Comment: Dear all, I hope this is the right place to report this problem. I am a Fedora 19 user with bash 4.2.45(1)-release installed. It seems that the new bash programmable completions are being distributed and enabled by default on several systems since a few months now. This raises several problems, the most critical one being that some completions are now based on a list of extensions associated to each program. Here are 3 examples which I encoutered and finally decided me to make this report: 1) say I have a PDF file named myfile.pdf-saved: this file name won't tab-complete with my favorite PDF reader. 2) say I have a PDF file named myfile (no extension): this file name won't tab-complete with my favorite PDF reader. 3) say I have a file named myfile.avi: this file name won't tab-complete with my favorite text editor (I often create companion ascii files to my avi files: I just type vi myfile.avi with the help of the completion -names are often cumbersome-, and then just rename the extension). In other words, the current default breaks tab-completions of files: 1) with unexpected file extensions regarding its content, 2) with no file extension at all, 3) with unsupported file content. By break I mean that there is no completion at all, and no related warning issued to the user. Given the fact that the standard bash behavior is to provide completion for all files when using TAB, this new behavior is at least a regression, if not a bug. The M-/ combination was introduced to retrieve the old behavior, but still: TAB is broken. The key of the problem is not the programmable completion, it is that the completion based on file extension 1) is enabled by default (opt-out) 2) to some predefined defaults. On the other hand I think there is no problem with the other rules (e.g. completing command keywords is a nice feature), since they do not seem to break anything. So, is there any hope to make the programmable completions based on file extension as NOT the default? For example making them opt-in, or enable them using a special key combination like M-/ Thanks. -- Comment By: Ville Skyttä (scop-guest) Date: 2013-12-17 19:21 Message: Completing based on file extensions is an intentional feature that bash-completion has always had; it is not broken, regression, or a bug. COMP_FILEDIR_FALLBACK does however implement some of what you're requesting, see http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=blob;f=doc/bash_completion.txt;h=c6e53d4c0534416d2507607ee9a90f1b1dd3abe9;hb=HEAD -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314549group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314549] Programmable completions based on file extension introduce regression
bash-completion-Bugs item #314549 was changed at 17/12/2013 21:38 by Sebastien Bardeau You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314549group_id=100114 Status: Closed Priority: 3 Submitted By: Sebastien Bardeau (bardeau-guest) Assigned to: Nobody (None) Summary: Programmable completions based on file extension introduce regression Distribution: Fedora / Red Hat Originally reported in: None Milestone: None Status: Won't Fix Original bug number: Initial Comment: Dear all, I hope this is the right place to report this problem. I am a Fedora 19 user with bash 4.2.45(1)-release installed. It seems that the new bash programmable completions are being distributed and enabled by default on several systems since a few months now. This raises several problems, the most critical one being that some completions are now based on a list of extensions associated to each program. Here are 3 examples which I encoutered and finally decided me to make this report: 1) say I have a PDF file named myfile.pdf-saved: this file name won't tab-complete with my favorite PDF reader. 2) say I have a PDF file named myfile (no extension): this file name won't tab-complete with my favorite PDF reader. 3) say I have a file named myfile.avi: this file name won't tab-complete with my favorite text editor (I often create companion ascii files to my avi files: I just type vi myfile.avi with the help of the completion -names are often cumbersome-, and then just rename the extension). In other words, the current default breaks tab-completions of files: 1) with unexpected file extensions regarding its content, 2) with no file extension at all, 3) with unsupported file content. By break I mean that there is no completion at all, and no related warning issued to the user. Given the fact that the standard bash behavior is to provide completion for all files when using TAB, this new behavior is at least a regression, if not a bug. The M-/ combination was introduced to retrieve the old behavior, but still: TAB is broken. The key of the problem is not the programmable completion, it is that the completion based on file extension 1) is enabled by default (opt-out) 2) to some predefined defaults. On the other hand I think there is no problem with the other rules (e.g. completing command keywords is a nice feature), since they do not seem to break anything. So, is there any hope to make the programmable completions based on file extension as NOT the default? For example making them opt-in, or enable them using a special key combination like M-/ Thanks. -- Comment By: Sebastien Bardeau (bardeau-guest) Date: 17/12/2013 21:38 Message: Completing based on file extensions is an intentional feature that bash-completion has always had; it is not broken, regression, or a bug. Ok. So getting back to my very first sentence, this is not the right place to report the regression I experience. Who is in charge of defining the bash-completion RULES based on file extensions? Is it the bash team, the bash-completion team, or my Linux distribution vendor? And who is in charge of enabling or not those rules? COMP_FILEDIR_FALLBACK does however implement some of what you're requesting, see Sorry but this does not help to find back the historical behavior of bash I use to know since 15 years. For now I just uninstall the bash-completion package if I am superuser, or just remove all rules (complete -r) if I am a standard user. Best regards. -- Comment By: Ville Skyttä (scop-guest) Date: 17/12/2013 17:21 Message: Completing based on file extensions is an intentional feature that bash-completion has always had; it is not broken, regression, or a bug. COMP_FILEDIR_FALLBACK does however implement some of what you're requesting, see http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=blob;f=doc/bash_completion.txt;h=c6e53d4c0534416d2507607ee9a90f1b1dd3abe9;hb=HEAD -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314549group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314533] SSH Completion Failed
bash-completion-Bugs item #314533 was changed at 2013-12-07 00:05 by Ville
Skyttä
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114
Status: Open
Priority: 3
Submitted By: Neville Gao (figod-guest)
Assigned to: Nobody (None)
Summary: SSH Completion Failed
Distribution: Debian
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
Following message[1] appears when I type 'ssh TAB' every time. I attached my
.ssh/config and proposal patch.
[1] sed: -e expression #1, char 97: invalid reference \2 on `s' command's RHS
--
Comment By: Ville Skyttä (scop-guest)
Date: 2013-12-07 00:05
Message:
I cannot reproduce, I get no errors when I complete with your config, so more
details are needed.
Looking at the patch, I'm confused; are you sure you got it the right way?
Turning \{0,1\} into ? and \{1,\} into + is introducing a sed portability
issue, and removing the backslash from front of ( and ) actually *introduces*
the invalid reference \2 errors you're seeing as the unescaped parenthesis
are no longer capturing groups...?
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314533] SSH Completion Failed
bash-completion-Bugs item #314533, was opened at 2013-12-04 20:13 by Neville Gao You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114 Status: Open Priority: 3 Submitted By: Neville Gao (figod-guest) Assigned to: Nobody (None) Summary: SSH Completion Failed Distribution: Debian Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Following message[1] appears when I type 'ssh TAB' every time. I attached my .ssh/config and proposal patch. [1] sed: -e expression #1, char 97: invalid reference \2 on `s' command's RHS -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314533group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314523] bash completion with autofs and ldap make ldap overload
bash-completion-Bugs item #314523, was opened at 22/11/2013 14:24 You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314523group_id=100114 Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: bash completion with autofs and ldap make ldap overload Distribution: Debian Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Hello, I use autofs with ldap maps to mount nfs groups dirs. in my case, autofs handle /home . if i go to /home , and press for exemple zTAB to use bash completion, it make ldap request and try to mount all.results: root@a12p51:~# cd /home root@a12p51:/home# zTAB zcat zdiff zeisstopnmzfgrepzic zipgrep zipsplit zmore zxpdf zcav zdump zeitgeist-daemon zforcezip zipinfo zjsdecode znew zcmp zegrepzenityzgrep zipcloak zipnote zless zsoelim - Whats this make in autofs and ldap: ookup_mount: lookup(ldap): looking up z do_bind: lookup(ldap): auth_required: 1, sasl_mech (null) do_bind: lookup(ldap): ldap simple bind returned 0 get_query_dn: lookup(ldap): found query dn ou=auto.home,ou=autofs,dc=fil.univ-lille1,dc=fr lookup_one: lookup(ldap): searching for ((objectclass=automount)(|(cn=z)(cn=/)(cn=\2A))) under ou=auto.home,ou=autofs,dc=fil.univ-lille1,dc=fr lookup_one: lookup(ldap): getting first entry for cn=z lookup_one: lookup(ldap): got answer, but no entry for ((objectclass=automount)(|(cn=z)(cn=/)(cn=\2A))) key z not found in map source(s). dev_ioctl_send_fail: token = 322 failed to mount /home/z handle_packet: type = 3 handle_packet_missing_indirect: token 323, name zcat, request pid 3570 attempting to mount entry /home/zcat lookup_mount: lookup(ldap): looking up zcat do_bind: lookup(ldap): auth_required: 1, sasl_mech (null) do_bind: lookup(ldap): ldap simple bind returned 0 lookup_one: lookup(ldap): searching for ((objectclass=automount)(|(cn=zcat)(cn=/)(cn=\2A))) under ou=auto.home,ou=autofs,dc=fil.univ-lille1,dc=fr lookup_one: lookup(ldap): getting first entry for cn=zcat lookup_one: lookup(ldap): got answer, but no entry for ((objectclass=automount)(|(cn=zcat)(cn=/)(cn=\2A))) key zcat not found in map source(s). dev_ioctl_send_fail: token = 323 failed to mount /home/zcat handle_packet: type = 3 handle_packet_missing_indirect: token 324, name zdiff, request pid 3570 attempting to mount entry /home/zdiff lookup_mount: lookup(ldap): looking up zdiff do_bind: lookup(ldap): auth_required: 1, sasl_mech (null) do_bind: lookup(ldap): ldap simple bind returned 0 lookup_one: lookup(ldap): searching for ((objectclass=automount)(|(cn=zdiff)(cn=/)(cn=\2A))) under ou=auto.home,ou=autofs,dc=fil.univ-lille1,dc=fr lookup_one: lookup(ldap): getting first entry for cn=zdiff lookup_one: lookup(ldap): got answer, but no entry for ((objectclass=automount)(|(cn=zdiff)(cn=/)(cn=\2A))) key zdiff not found in map source(s). dev_ioctl_send_fail: token = 324 failed to mount /home/zdiff handle_packet: type = 3 handle_packet_missing_indirect: token 325, name zeisstopnm, request pid 3570 attempting to mount entry /home/zeisstopnm lookup_mount: lookup(ldap): looking up zeisstopnm do_bind: lookup(ldap): auth_required: 1, sasl_mech (null) do_bind: lookup(ldap): ldap simple bind returned 0 lookup_one: lookup(ldap): searching for ((objectclass=automount)(|(cn=zeisstopnm)(cn=/)(cn=\2A))) under ou=auto.home,ou=autofs,dc=fil.univ-lille1,dc=fr lookup_one: lookup(ldap): getting first entry for cn=zeisstopnm lookup_one: lookup(ldap): got answer, but no entry for ((objectclass=automount)(|(cn=zeisstopnm)(cn=/)(cn=\2A))) key zeisstopnm not found in map source(s). dev_ioctl_send_fail: token = 325 failed to mount /home/zeisstopnm - And this fao all the result. If i go to /home and press TABTAB this make aver 4000 request to ldap and make the server averloaded. There is a solution to this problem? Thank you! Mike -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314523group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314501] PATH: pypy support
bash-completion-Bugs item #314501, was opened at 2013-10-24 14:09 by Stefano Rivera You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314501group_id=100114 Status: Open Priority: 3 Submitted By: Stefano Rivera (stefanor) Assigned to: Nobody (None) Summary: PATH: pypy support Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Here's a simple patch to extend the python completion, to support pypy. pypy is a drop-in replacement for cPython, so the argument parsing is identical. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314501group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314501] PATH: pypy support
bash-completion-Bugs item #314501 was changed at 2013-10-24 14:10 by Stefano Rivera You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314501group_id=100114 Status: Open Priority: 3 Submitted By: Stefano Rivera (stefanor) Assigned to: Nobody (None) Summary: PATH: pypy support Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Here's a simple patch to extend the python completion, to support pypy. pypy is a drop-in replacement for cPython, so the argument parsing is identical. -- Comment By: Stefano Rivera (stefanor) Date: 2013-10-24 14:10 Message: err s/PATH/PATCH/ -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314501group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314457] tar completion only handles dashless style
bash-completion-Bugs item #314457 was changed at 2013-10-01 09:45 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314457group_id=100114 Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: tar completion only handles dashless style Distribution: --Distribution-Agnostic-- Originally reported in: Fedora / Red Hat Bugzilla Milestone: None Status: None Original bug number: 1013776 Initial Comment: Anonymous message posted by mans...@oxplot.com I'm not used to the usual dashless (is it called BSD style cmd line options?) style options as many aren't (e.g. tar xf some.tar.gz). However, the current completion script for tar only accepts that style and no other. Incomplete if you ask me :) I rewrote the majority of it to make it very flexible, working with short/long/dashless style options, so things like: $ tar f press-tab-here -x --bzip2 would work fine (ie list only bzip2 compressed files in cwd). This is my first time writing a bash-completion script and I tried to retain as much code as possible. I have also done a good deal of testing, but do please do some more if can. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314457group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314457] tar completion only handles dashless style
bash-completion-Bugs item #314457, was opened at 2013-09-30 17:58 You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314457group_id=100114 Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: tar completion only handles dashless style Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Anonymous message posted by mans...@oxplot.com I'm not used to the usual dashless (is it called BSD style cmd line options?) style options as many aren't (e.g. tar xf some.tar.gz). However, the current completion script for tar only accepts that style and no other. Incomplete if you ask me :) I rewrote the majority of it to make it very flexible, working with short/long/dashless style options, so things like: $ tar f press-tab-here -x --bzip2 would work fine (ie list only bzip2 compressed files in cwd). This is my first time writing a bash-completion script and I tried to retain as much code as possible. I have also done a good deal of testing, but do please do some more if can. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314457group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314451] Adding .[0-9]* in _install_xspec regexp for ghostview
bash-completion-Bugs item #314451, was opened at 2013-09-25 03:13 by Max Akhmedov You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314451group_id=100114 Status: Open Priority: 3 Submitted By: Max Akhmedov (zlobober-guest) Assigned to: Nobody (None) Summary: Adding .[0-9]* in _install_xspec regexp for ghostview Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: Metapost usually produces output files with extensions like .1, .2 etc. By default it's impossible to autocomplete such files when using gv, so it's useful to add numeric extensions recognition with something like: _install_xspec '!*.@(@(?(e)ps|?(E)PS|pdf|PDF|[0-9]*)?(.gz|.GZ|.bz2|.BZ2|.Z))' gv ggv kghostview -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detailatid=413095aid=314451group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][314417] completion for cc and c++ does not work
bash-completion-Bugs item #314417 was changed at 2013-09-07 10:07 by Ville
Skyttä
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detailatid=413095aid=314417group_id=100114
Status: Closed
Priority: 3
Submitted By: Nobody (None)
Assigned to: Ville Skyttä (scop-guest)
Summary: completion for cc and c++ does not work
Distribution: Ubuntu
Originally reported in: None
Milestone: None
Status: Fix Committed
Original bug number:
Initial Comment:
Anonymous message posted by corbellini.and...@gmail.com
Typing cc TAB at the bash prompt does not give any hint.
The problem lies in the following piece of
/usr/share/bash-completion/completions/cc:
complete -F _gcc gcc g++ g77 gcj gpc {
cc --version 2/dev/null | grep -q GCC complete -F _gcc cc || :
c++ --version 2/dev/null | grep -q GCC complete -F _gcc c++ || :
}
cc/gcc/c++/g++ --version do not print GCC, therefore the completion for
cc/c++ is never installed.
I suggest to use this check instead:
[[ $(readlink -f /usr/bin/cc) == $(readlink -f /usr/bin/gcc) ]]
However a problem still remains: when cc is not GCC, there is no completion.
Therefore
|| :
should be replaced with
|| complete -F _minimal cc
--
Comment By: Ville Skyttä (scop-guest)
Date: 2013-09-07 10:07
Message:
http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=d6600e6a10a370961b4bd4e1e060ba79e080a8d7
http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=ffabc6f2829201815c1a9c69cfdf8bdbe77ff648
--
Comment By: Ville Skyttä (scop-guest)
Date: 2013-09-06 13:16
Message:
The point is: pkgversion_string is configurable
When I asked your cc --version output you mentioned And it should be the same
for everyone -- I just wanted to point out that being configurable it
certainly isn't and shouldn't be the same for everyone, that's all. But
nevermind.
I suppose we could try the _realcommand approach additionally if needed after
examining the command output.
--
Comment By: Andrea Corbellini (andrea.corbellini-guest)
Date: 2013-09-06 13:04
Message:
print_version uses pkgversion_string in its output, and that's controlled by
gcc's configure script, GCC being the default:
The point is: pkgversion_string is configurable and relying on it makes
bash-completion not portable, like readlink.
So checking for GCC or Ubuntu is not the right thing to do, IMO.
Using _realcommand(), although it is still a flawed solution for many reasons,
seems a better alternative.
--
Comment By: Ville Skyttä (scop-guest)
Date: 2013-09-06 12:56
Message:
print_version uses pkgversion_string in its output, and that's controlled by
gcc's configure script, GCC being the default:
$ ./configure --help | grep pkgversion
--with-pkgversion=PKG Use PKG in the version string in place of GCC
Assuming gcc if --version contains Ubuntu would be one way to approach this,
but doesn't give me a warm fuzzy feeling.
And yes, not falling back to _minimal for non-gcc is a bug, will fix.
--
Comment By: Andrea Corbellini (andrea.corbellini-guest)
Date: 2013-09-06 11:05
Message:
Our cc completion is specifically a gcc one, so we explicitly do not want to
install it to anything else but gcc.
My cc is gcc.
Also, it's true that you support just gcc, but you should also handle the case
where gcc is not installed (and use _minimal in that case).
And the suggested readlink approach is flawed in multiple ways, readlink -f
is not portable (the _realcommand() function could be used instead of it),
and the binaries might not be in /usr/bin.
If your cc --version (assuming cc is gcc) output doesn't contain GCC, what
does it output?
cc (Ubuntu/Linaro 4.8.1-9ubuntu1) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And it should be the same for everyone:
http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/gcc.c?view=markup (look for if
(print_version)).
--
Comment By: Ville Skyttä (scop-guest)
Date: 2013-09-06 10:40
Message:
Our cc completion is specifically a gcc one, so we explicitly do not want to
install it to anything else but gcc. And the suggested readlink approach is
flawed in multiple ways, readlink -f is not portable (the _realcommand()
function could be used instead of it), and the binaries might not be in
/usr/bin.
If your cc --version (assuming cc is gcc) output doesn't contain GCC, what does
it output
