[Bash-completion-devel] [bash-completion-Bugs][31 1383] DBTS 282799: completion of fd redirect after f ind command limited to directories
Bugs item #311383, was opened at 30/01/2009 09:14 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 282799: completion of fd redirect after find command limited to directories Distribution: None Initial Comment: find > foo ask for autocompletion there, only directories are taken into account. ls > foo or cat > foo autocomplete to all filenames (directories and non-directories), as it should. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311383&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1383] DBTS 282799: completion of fd redirect after f ind command limited to directories
Bugs item #311383, was opened at 30/01/2009 09:14 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 282799: completion of fd redirect after find command limited to directories Distribution: None >Originally reported in: Debian BTS Original bug number: 282799 Initial Comment: find > foo ask for autocompletion there, only directories are taken into account. ls > foo or cat > foo autocomplete to all filenames (directories and non-directories), as it should. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311383&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1384] DBTS 336987: shell variables should always be a valid completion when syntactically valid
Bugs item #311384, was opened at 30/01/2009 09:21 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 336987: shell variables should always be a valid completion when syntactically valid Distribution: None Originally reported in: Debian BTS Original bug number: 336987 Initial Comment: Normally, bash can complete shell variables when appropriate; for example, "foo=1" followed by "echo $f" will complete to "echo $foo". However, programmable completion interferes with this; for example, "svn ls $f", "cvs $f", and "ssh $f" all fail to complete $foo. Shell variables should always be a valid completion when they are syntactically valid, since they could always contain a string appropriate for the current command. (By "when they are syntactically valid", I mean that the shell already knows not to complete "echo \$f" into "echo \$foo", and that shouldn't change.) -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311384&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1385] DBTS 427758: filenames starting with =
Bugs item #311385, was opened at 30/01/2009 09:30 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 427758: filenames starting with = Distribution: None Originally reported in: Debian BTS Original bug number: 427758 Initial Comment: $ touch =foo $ echo = Expansion results in "=\=foo" rather than "\=foo". -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311385&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1385] DBTS 427758: filenames starting with =
Bugs item #311385, was opened at 30/01/2009 09:30 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 427758: filenames starting with = Distribution: None Originally reported in: Debian BTS Original bug number: 427758 Initial Comment: $ touch =foo $ echo = Expansion results in "=\=foo" rather than "\=foo". -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 09:32 Message: It doesn't happen anymore with our bzr revision, but still shows a bug: $ mkdir /tmp/foo $ cd /tmp $ touch foo/=bar $ echo foo/= $ echo foo/=bar If there are other files in /tmp/foo/, it behaves oddly: $ touch foo/buz foo/foo $ echo foo/= claws-mail-1000 orbit-neo/ foo/.pcmanfm-socket:0.0-neo gconfd-neo/ serverauth.lwDVrycexY gpg-HiLpT3/ ssh-vyyNyO3687/ .ICE-unix/ .X0-lock liferea.neo.3796948728 .X11-unix/ .lxterminal-socket:0.0-neo $ (i.e. shows files in /tmp/ and not /tmp/foo/) -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311385&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1386] DBTS 503317: function _dpkg_source contain s a inappropriate exit statement
Bugs item #311386, was opened at 30/01/2009 09:37
Status: Open
Priority: 3
Submitted By: David Paleino (hanska-guest)
Assigned to: Nobody (None)
Summary: DBTS 503317: function _dpkg_source contains a inappropriate exit
statement
Distribution: Debian
Originally reported in: Debian BTS
Original bug number: 503317
Initial Comment:
_dpkg_source contains a inappropriate exit statement, which forces
the shell to exit. I suppose this should be 'return' instead.
Reproduce: Open a bash-shell , type '_dpkg_source'.
Patch follows:
diff -c -L /su:r...@localhost:/etc/bash_completion -L
/tmp/buffer-content-2677a0z /tmp/tramp.2677M-C /tmp/buffer-content-2677a0z
*** /su:r...@localhost:/etc/bash_completion
--- /tmp/buffer-content-2677a0z
***
*** 4457,4463
COMPREPLY=()
if [ "$1" != "dpkg-source" ]; then
! exit 1
fi
cur=`_get_cword`
prev=${COMP_WORDS[COMP_CWORD-1]}
--- 4457,4463
COMPREPLY=()
if [ "$1" != "dpkg-source" ]; then
! return 1
fi
cur=`_get_cword`
prev=${COMP_WORDS[COMP_CWORD-1]}
--
You can respond by visiting:
http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311386&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1386] DBTS 503317: function _dpkg_source contain s a inappropriate exit statement
Bugs item #311386, was opened at 30/01/2009 09:37
>Status: Closed
Priority: 3
Submitted By: David Paleino (hanska-guest)
>Assigned to: David Paleino (hanska-guest)
Summary: DBTS 503317: function _dpkg_source contains a inappropriate exit
statement
Distribution: Debian
Originally reported in: Debian BTS
Original bug number: 503317
Initial Comment:
_dpkg_source contains a inappropriate exit statement, which forces
the shell to exit. I suppose this should be 'return' instead.
Reproduce: Open a bash-shell , type '_dpkg_source'.
Patch follows:
diff -c -L /su:r...@localhost:/etc/bash_completion -L
/tmp/buffer-content-2677a0z /tmp/tramp.2677M-C /tmp/buffer-content-2677a0z
*** /su:r...@localhost:/etc/bash_completion
--- /tmp/buffer-content-2677a0z
***
*** 4457,4463
COMPREPLY=()
if [ "$1" != "dpkg-source" ]; then
! exit 1
fi
cur=`_get_cword`
prev=${COMP_WORDS[COMP_CWORD-1]}
--- 4457,4463
COMPREPLY=()
if [ "$1" != "dpkg-source" ]; then
! return 1
fi
cur=`_get_cword`
prev=${COMP_WORDS[COMP_CWORD-1]}
--
>Comment By: David Paleino (hanska-guest)
Date: 30/01/2009 09:37
Message:
Fixed in r1195.
--
You can respond by visiting:
http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311386&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1387] DBTS 506973: soft link completion is broken
Bugs item #311387, was opened at 30/01/2009 09:39 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 506973: soft link completion is broken Distribution: None Originally reported in: Debian BTS Original bug number: 506973 Initial Comment: Bash completion fails to account for soft links properly: nsla...@mahora: ~ $ mkdir -p dir-a/dir-b nsla...@mahora: ~ $ ln -s dir-a/dir-b dir-c nsla...@mahora: ~ $ touch doc-a nsla...@mahora: ~ $ touch doc-b nsla...@mahora: ~ $ cd dir-c nsla...@mahora: ~/dir-c $ cat ../doc- doc-a doc-b nsla...@mahora: ~/dir-c $ cat ../doc-a cat: ../doc-a: No such file or directory nsla...@mahora: ~/dir-c $ cat ../doc-ab cat: ../doc-b: No such file or directory -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311387&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1388] 'ci -u prefix' hit on RCS/prefix sh adows ./prefix
Bugs item #311388, was opened at 30/01/2009 09:41 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: 'ci -u prefix' hit on RCS/prefix shadows ./prefix Distribution: None Originally reported in: Debian BTS Original bug number: 299229 Initial Comment: If you have a file RCS/prefix1st-file,v but not RCS/prefix2nd-file,v and want to do an initial check-in of ./prefix2nd-file, then, if you do ci -u prefix the bash completion turns it into ci -u ./prefix1st-file unconditionally, w/o giving you the opportunity to select the 2nd file. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311388&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1388] DBTS 299229: 'ci -u prefix' hit o n RCS/prefix shadows ./prefix
Bugs item #311388, was opened at 30/01/2009 09:41 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) >Summary: DBTS 299229: 'ci -u prefix' hit on RCS/prefix shadows ./prefix Distribution: None Originally reported in: Debian BTS Original bug number: 299229 Initial Comment: If you have a file RCS/prefix1st-file,v but not RCS/prefix2nd-file,v and want to do an initial check-in of ./prefix2nd-file, then, if you do ci -u prefix the bash completion turns it into ci -u ./prefix1st-file unconditionally, w/o giving you the opportunity to select the 2nd file. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311388&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1389] DBTS 350232: shopt -s no_empty_cmd_compl etion not quite durable enough
Bugs item #311389, was opened at 30/01/2009 09:42 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 350232: shopt -s no_empty_cmd_completion not quite durable enough Distribution: None Originally reported in: Debian BTS Original bug number: 350232 Initial Comment: `shopt -s no_empty_cmd_completion' allows us to paste in segments of bash scripts with indenting via X's copy buffer, without erronously triggering bash completion. However, it only works if we use either tabs or spaces exclusively in the scripts being copied. If a line being pasted contains a bunch of spaces, then a tab, then completion is attempted on all ~4000 items in one's PATH. Spaces alone should hence be treated as an empty readline buffer for the purposes of no_empty_cmd_completion. Alternatively, if it is at all possible to detect that the contents of a copy buffer are being pasted into bash (via either shift-insert, or the middle mouse button), then bash should have the option to turn off completion all together, for the duration of the copy. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311389&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1390] DBTS 466067: complete-into-brace should use pr ogrammable completion
Bugs item #311390, was opened at 30/01/2009 09:45 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 466067: complete-into-brace should use programmable completion Distribution: None Originally reported in: Debian BTS Original bug number: 466067 Initial Comment: complete-into-braces, as documented, performs filename completion. This is quite awkwards, since when a programmable completion is available, it means in many cases that filenames are not valid completions. I do agree that it would not be reasonable to expand to all possible completions, since eg. it would be pointless to expand all possible option flags - this example shows that the problem is not trivial to handle. OTOH, it would seem that a first intermediary step would be useful, by allowing brace completion of everything returned by the pgorammable completion, that does not start with a hyphen. For cases where it does make sense, it is a huge usability improvement, and for cases where it does not, it is likely not to make less sense than brace-completing filenames - anyway, as today, the user can undo the expansion if it does not fit. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311390&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1391] DBTS 471266: lvm completion does not work prop erly
Bugs item #311391, was opened at 30/01/2009 09:46 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 471266: lvm completion does not work properly Distribution: None Originally reported in: Debian BTS Original bug number: 471266 Initial Comment: Command line completion (in /etc/bash_completion) for the lvm2 suite of tools does not work very well and it would be better to remove it altogether. Examples of broken behaviour: # lvextend --size This only allows completion on the words in the list "g G k K m M t T". However a number must also be entered before the the units and then the units cannot be completed. This is of such marginal utility that is should be removed (IMHO). # lvextend --size +40G The completes on the physical volumes, not the logical volumes as it should. This is because it counts "+40G" as the logical volume (the first non-option argument) and assumes that a physical volume path is now needed. I think there are a number of other situations when the completion fails. I always seem to have to type a path to the logical volume without tab completion available. It would be better if it did not try any specific completion at all. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311391&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1392] DBTS 489258: ssh completion only looks for exe cutables
Bugs item #311392, was opened at 30/01/2009 09:47 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 489258: ssh completion only looks for executables Distribution: None Originally reported in: Debian BTS Original bug number: 489258 Initial Comment: Asking for completion on "ssh u...@host tar -zxf " looks for executables in the path: looks like the ssh rule is not flexible enough to be useful here. Not sure it is feasible (or even that it would generally make sense) to attempt getting a completion from a remote bash ? At the very least, it would be no less useful, but less expensive, to fallback to file completion. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311392&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1393] DBTS 501479: don't assume sed being GNU sed on Linux systems
Bugs item #311393, was opened at 30/01/2009 09:49 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 501479: don't assume sed being GNU sed on Linux systems Distribution: None Originally reported in: Debian BTS Original bug number: 501479 Initial Comment: * bash-completion assumes that a uname of Linux implies that the "sed" command refers to GNU sed, while on other systems it aliases sed to "gsed" if present. While not possible on Debian, someone could easily make a Linux system with GNU sed installed as "gsed" and some other standards-compliant sed installed as "sed". Why bother having the check for Linux at all? Just always use "gsed" if present. Incidentally, bash-completion also leaves the alias sed=gsed in place if added, which seems like a surprising side-effect to occur due to sourcing bash-completion. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311393&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1394] DBTS 501836: check for conflicts with killall5 (killall on SysV) for killall, pkill and pgrep co mpletions
Bugs item #311394, was opened at 30/01/2009 09:50 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 501836: check for conflicts with killall5 (killall on SysV) for killall, pkill and pgrep completions Distribution: None Originally reported in: Debian BTS Original bug number: 501836 Initial Comment: * Completion for killall, pkill, and pgrep depends on a uname of Linux or FreeBSD. I suspect this relates to the identically named but drastically different SysV killall command, found as "killall5" on Debian systems. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311394&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1395] DBTS 503691: does not complete files and direc tories as arguments
Bugs item #311395, was opened at 30/01/2009 09:51 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 503691: does not complete files and directories as arguments Distribution: None Originally reported in: Debian BTS Original bug number: 503691 Initial Comment: Hi David, as discussed in Palermo, here my bug report. It makes me crazy that so many programs taking files or directories as arguments cannot be completed. Example: cowbuilder --create --distribution etch --basepath /var/cache/pbu does NOT complete to /var/cache/pbuilder/, although the directory is there. Same with our TeX packing scripts: perl tpm2deb-source.pl make-orig-tar --master=/src/TeX/Mas or perl tpm2deb-source.pl make-orig-tar --master /src/TeX/Mas in both cases it never completes to /src/TeX/Master-2007.0 which is there. I assume that in lack of any information, in former times bash completion did path name completion, but now it does nothing. That is not good. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311395&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1396] DBTS 511788: completion of usernames broken
Bugs item #311396, was opened at 30/01/2009 09:52 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 511788: completion of usernames broken Distribution: None Originally reported in: Debian BTS Original bug number: 511788 Initial Comment: Hi. Completion of usernames is broken and "\: " or \ is inserted e.g. chown cuser\: (space at the end) chown calestyo\\\:calestyo etc. etc. Completion of users/groups with a "." (which is widely used at big sites like firstname.secondname) and perhaps with other strange characters is even more broken ^^ Thanks, Chris. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311396&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1397] DBTS 267060: completion error commands/directo ries conflict
Bugs item #311397, was opened at 30/01/2009 09:54 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 267060: completion error commands/directories conflict Distribution: None Originally reported in: Debian BTS Original bug number: 267060 Initial Comment: From: Grahame To: Debian Bug Tracking System Subject: bash: completion error commands/directories conflict Date: Fri, 20 Aug 2004 14:25:57 +0100 Package: bash Version: 3.0-5 Severity: normal if you have a directory that is the same name as a system command then the directory will be completed when tab is pressed and not the command. For example I have mutella installed and I also have a directory called mutella in my home directory. Now if I type mutel and then press tab (whilst in my home directory) bash completes it to mutella/ and when return is then pressed bash complains: -bash: mutella/: is a directory -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311397&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1397] DBTS 267060: completion error commands/directo ries conflict
Bugs item #311397, was opened at 30/01/2009 09:54 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 267060: completion error commands/directories conflict Distribution: None Originally reported in: Debian BTS Original bug number: 267060 Initial Comment: From: Grahame To: Debian Bug Tracking System Subject: bash: completion error commands/directories conflict Date: Fri, 20 Aug 2004 14:25:57 +0100 Package: bash Version: 3.0-5 Severity: normal if you have a directory that is the same name as a system command then the directory will be completed when tab is pressed and not the command. For example I have mutella installed and I also have a directory called mutella in my home directory. Now if I type mutel and then press tab (whilst in my home directory) bash completes it to mutella/ and when return is then pressed bash complains: -bash: mutella/: is a directory -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 09:55 Message: From: Matthias Klose To: Grahame , 267...@bugs.debian.org Cc: c...@po.cwru.edu Subject: Re: Bug#267060: bash: completion error commands/directories conflict Date: Sat, 28 Aug 2004 15:55:43 +0200 Grahame writes: > if you have a directory that is the same name as a system command then the > directory will be completed when tab is pressed and not the command. > > For example I have mutella installed and I also have a directory called > mutella in my home directory. > > Now if I type mutel and then press tab (whilst in my home directory) bash > completes it to mutella/ and when return is then pressed bash complains: > > -bash: mutella/: is a directory you could set mark-directories off in your .inputrc. AFAIK there is no way to tell which of the two choices takes precedence. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311397&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1397] DBTS 267060: completion error commands/directo ries conflict
Bugs item #311397, was opened at 30/01/2009 09:54 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 267060: completion error commands/directories conflict Distribution: None Originally reported in: Debian BTS Original bug number: 267060 Initial Comment: From: Grahame To: Debian Bug Tracking System Subject: bash: completion error commands/directories conflict Date: Fri, 20 Aug 2004 14:25:57 +0100 Package: bash Version: 3.0-5 Severity: normal if you have a directory that is the same name as a system command then the directory will be completed when tab is pressed and not the command. For example I have mutella installed and I also have a directory called mutella in my home directory. Now if I type mutel and then press tab (whilst in my home directory) bash completes it to mutella/ and when return is then pressed bash complains: -bash: mutella/: is a directory -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 09:57 Message: From: Chet Ramey To: Grahame , 267...@bugs.debian.org Cc: c...@po.cwru.edu, Matthias Klose Subject: Re: Bug#267060: bash: completion error commands/directories conflict Date: Sat, 28 Aug 2004 11:03:26 -0400 Matthias Klose wrote: > Grahame writes: > >>if you have a directory that is the same name as a system >> command then the directory will be completed when tab is >> pressed and not the command. >> >>For example I have mutella installed and I also have a >> directory called mutella in my home directory. >> >>Now if I type mutel and then press tab (whilst in my home >> directory) bash completes it to mutella/ and when return >> is then pressed bash complains: >> >>-bash: mutella/: is a directory > > > you could set mark-directories off in your .inputrc. > AFAIK there is no way to tell which of the two choices > takes precedence. Damned if you do, damned if you don't. At various times in bash's development history, I have implemented all three options: let the command take precedence and append a space, let the directory take precedence and append a slash, and append nothing. Every alternative generated its own set of complaints, some more vitriolic than others. I'm favoring returning to the `append nothing' strategy and forcing the user to determine the appropriate alternative in an inherently ambiguous situation. Chet -- Comment By: David Paleino (hanska-guest) Date: 30/01/2009 09:55 Message: From: Matthias Klose To: Grahame , 267...@bugs.debian.org Cc: c...@po.cwru.edu Subject: Re: Bug#267060: bash: completion error commands/directories conflict Date: Sat, 28 Aug 2004 15:55:43 +0200 Grahame writes: > if you have a directory that is the same name as a system command then the > directory will be completed when tab is pressed and not the command. > > For example I have mutella installed and I also have a directory called > mutella in my home directory. > > Now if I type mutel and then press tab (whilst in my home directory) bash > completes it to mutella/ and when return is then pressed bash complains: > > -bash: mutella/: is a directory you could set mark-directories off in your .inputrc. AFAIK there is no way to tell which of the two choices takes precedence. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311397&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1397] DBTS 267060: completion error commands/directo ries conflict
Bugs item #311397, was opened at 30/01/2009 09:54 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 267060: completion error commands/directories conflict Distribution: None Originally reported in: Debian BTS Original bug number: 267060 Initial Comment: From: Grahame To: Debian Bug Tracking System Subject: bash: completion error commands/directories conflict Date: Fri, 20 Aug 2004 14:25:57 +0100 Package: bash Version: 3.0-5 Severity: normal if you have a directory that is the same name as a system command then the directory will be completed when tab is pressed and not the command. For example I have mutella installed and I also have a directory called mutella in my home directory. Now if I type mutel and then press tab (whilst in my home directory) bash completes it to mutella/ and when return is then pressed bash complains: -bash: mutella/: is a directory -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 09:58 Message: What do you think? Which approach should we take? Waiting for comments (I've marked this as "wontfix" in DBTS, since I prefer completing on directories, but discussion is welcome) David -- Comment By: David Paleino (hanska-guest) Date: 30/01/2009 09:57 Message: From: Chet Ramey To: Grahame , 267...@bugs.debian.org Cc: c...@po.cwru.edu, Matthias Klose Subject: Re: Bug#267060: bash: completion error commands/directories conflict Date: Sat, 28 Aug 2004 11:03:26 -0400 Matthias Klose wrote: > Grahame writes: > >>if you have a directory that is the same name as a system >> command then the directory will be completed when tab is >> pressed and not the command. >> >>For example I have mutella installed and I also have a >> directory called mutella in my home directory. >> >>Now if I type mutel and then press tab (whilst in my home >> directory) bash completes it to mutella/ and when return >> is then pressed bash complains: >> >>-bash: mutella/: is a directory > > > you could set mark-directories off in your .inputrc. > AFAIK there is no way to tell which of the two choices > takes precedence. Damned if you do, damned if you don't. At various times in bash's development history, I have implemented all three options: let the command take precedence and append a space, let the directory take precedence and append a slash, and append nothing. Every alternative generated its own set of complaints, some more vitriolic than others. I'm favoring returning to the `append nothing' strategy and forcing the user to determine the appropriate alternative in an inherently ambiguous situation. Chet -- Comment By: David Paleino (hanska-guest) Date: 30/01/2009 09:55 Message: From: Matthias Klose To: Grahame , 267...@bugs.debian.org Cc: c...@po.cwru.edu Subject: Re: Bug#267060: bash: completion error commands/directories conflict Date: Sat, 28 Aug 2004 15:55:43 +0200 Grahame writes: > if you have a directory that is the same name as a system command then the > directory will be completed when tab is pressed and not the command. > > For example I have mutella installed and I also have a directory called > mutella in my home directory. > > Now if I type mutel and then press tab (whilst in my home directory) bash > completes it to mutella/ and when return is then pressed bash complains: > > -bash: mutella/: is a directory you could set mark-directories off in your .inputrc. AFAIK there is no way to tell which of the two choices takes precedence. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311397&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1398] DBTS 297065: du --max-depth\= 1: invalid
Bugs item #311398, was opened at 30/01/2009 10:01 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 297065: du --max-depth\= 1: invalid Distribution: None Originally reported in: Debian BTS Original bug number: 297065 Initial Comment: From: Justin Pryzby To: Debian Bug Tracking System Subject: bash: [COMPLETION] du --max-depth\= 1: invalid Date: Sat, 26 Feb 2005 15:09:57 -0500 Package: bash Version: 2.05b-24 Severity: minor pryz...@cyberia:/tmp/gcc-3.4-3.4.3$ du --max-depth\= 1 -h debian/ du: invalid maximum depth `' Try `du --help' for more information. The extra space is rejected by the du argument parser. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311398&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1399] DBTS 313514: bash-completion fails with e.g ., ls and newlines in file names
Bugs item #311399, was opened at 30/01/2009 10:03 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 313514: bash-completion fails with e.g., ls and newlines in file names Distribution: None Originally reported in: Debian BTS Original bug number: 313514 Initial Comment: From: Anthony DeRobertis To: Debian Bug Tracking System Subject: bash-completion fails with e.g., ls and newlines in file names Date: Tue, 14 Jun 2005 01:37:41 -0400 Package: bash Version: 3.0-15 Severity: minor File: /etc/bash_completion anth...@bohr:foo$ touch "$(echo -e 'foo\nbar')" anth...@bohr:foo$ ls -b foo\nbar anth...@bohr:foo$ ls f bar foo Notice how instead of completing foo?bar (where ? = newline) it offers to complete either foo or bar. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311399&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1399] DBTS 313514: bash-completion fails with e.g ., ls and newlines in file names
Bugs item #311399, was opened at 30/01/2009 10:03 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 313514: bash-completion fails with e.g., ls and newlines in file names Distribution: None Originally reported in: Debian BTS Original bug number: 313514 Initial Comment: From: Anthony DeRobertis To: Debian Bug Tracking System Subject: bash-completion fails with e.g., ls and newlines in file names Date: Tue, 14 Jun 2005 01:37:41 -0400 Package: bash Version: 3.0-15 Severity: minor File: /etc/bash_completion anth...@bohr:foo$ touch "$(echo -e 'foo\nbar')" anth...@bohr:foo$ ls -b foo\nbar anth...@bohr:foo$ ls f bar foo Notice how instead of completing foo?bar (where ? = newline) it offers to complete either foo or bar. -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 10:04 Message: From: Mike Dornberger To: Debian Bug Tracking System <313...@bugs.debian.org> Subject: Re: bash-completion fails with e.g., ls and newlines in file names - workaround Date: Tue, 8 Nov 2005 11:29:30 +0100 Package: bash Version: 2.05b-26 Followup-For: Bug #313514 Hi, this bug hit me today, too, when I wanted to delete filenames with newlines. Completion for mv, rm and ls (haven't tested others) show this bug, even if you use M-* (insert-completions). $ rm fo results even to: $ rm bar foo It does not fail on e. g. echo: $ echo fo $ echo 'foo bar' (M-* works here correctly, too.) Interesting point is, that it _only_ seems to break on newlines. Doing $ touch "$(echo -e 'evil filename with\nan LF and other special chars ($bla) : , "')" $ rm ev results in: $ rm an\ LF\ and\ other\ special\ chars\ \(\$bla\)\ \:\ \,\ \" evil\ filename\ with As a little workaround one can either write $ echo rm ev or $ xrm ev then using C-a or Home and deleting "echo " or "x" before execution. The last one maybe only works if there isn't a xrm file/function/alias or something. And oh, I just found out, you can even do $ rm ev (M-/ is by default bound to complete-filename. M-x BTW can be entered as ESC x, too.) Greetings, Mike -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311399&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1399] DBTS 313514: bash-completion fails with e.g ., ls and newlines in file names
Bugs item #311399, was opened at 30/01/2009 10:03 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 313514: bash-completion fails with e.g., ls and newlines in file names Distribution: None Originally reported in: Debian BTS Original bug number: 313514 Initial Comment: From: Anthony DeRobertis To: Debian Bug Tracking System Subject: bash-completion fails with e.g., ls and newlines in file names Date: Tue, 14 Jun 2005 01:37:41 -0400 Package: bash Version: 3.0-15 Severity: minor File: /etc/bash_completion anth...@bohr:foo$ touch "$(echo -e 'foo\nbar')" anth...@bohr:foo$ ls -b foo\nbar anth...@bohr:foo$ ls f bar foo Notice how instead of completing foo?bar (where ? = newline) it offers to complete either foo or bar. -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 10:05 Message: From: Michael Tweedale To: 313...@bugs.debian.org Subject: Re: bash-completion fails with e.g., ls and newlines in file names - workaround Date: Thu, 18 May 2006 12:29:44 +0100 Package: bash Version: 3.1-4 Followup-For: Bug #313514 On 8 Nov 2005 at 11:29, Mike Dornberger wrote: > Interesting point is, that it _only_ seems to break on > newlines. It also chokes on filenames with an equals sign: $ touch x=y then $ ls x completes correctly; $ ls x= completes (bizarrely) to x=x\=y and $ x= as expected completes to a list of all filenames in cwd (though if . is in $PATH maybe it should complete to x=y ?). Best, Michael -- Comment By: David Paleino (hanska-guest) Date: 30/01/2009 10:04 Message: From: Mike Dornberger To: Debian Bug Tracking System <313...@bugs.debian.org> Subject: Re: bash-completion fails with e.g., ls and newlines in file names - workaround Date: Tue, 8 Nov 2005 11:29:30 +0100 Package: bash Version: 2.05b-26 Followup-For: Bug #313514 Hi, this bug hit me today, too, when I wanted to delete filenames with newlines. Completion for mv, rm and ls (haven't tested others) show this bug, even if you use M-* (insert-completions). $ rm fo results even to: $ rm bar foo It does not fail on e. g. echo: $ echo fo $ echo 'foo bar' (M-* works here correctly, too.) Interesting point is, that it _only_ seems to break on newlines. Doing $ touch "$(echo -e 'evil filename with\nan LF and other special chars ($bla) : , "')" $ rm ev results in: $ rm an\ LF\ and\ other\ special\ chars\ \(\$bla\)\ \:\ \,\ \" evil\ filename\ with As a little workaround one can either write $ echo rm ev or $ xrm ev then using C-a or Home and deleting "echo " or "x" before execution. The last one maybe only works if there isn't a xrm file/function/alias or something. And oh, I just found out, you can even do $ rm ev (M-/ is by default bound to complete-filename. M-x BTW can be entered as ESC x, too.) Greetings, Mike -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311399&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1400] DBTS 320390: Does not tab complete a file crea ted after tab is pressed once
Bugs item #311400, was opened at 30/01/2009 10:06 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 320390: Does not tab complete a file created after tab is pressed once Distribution: None Originally reported in: Debian BTS Original bug number: 320390 Initial Comment: From: Matt Kraai To: Debian Bug Tracking System Subject: bash: Does not tab complete a file created after tab is pressed once Date: Thu, 28 Jul 2005 15:30:15 -0700 Package: bash Version: 3.0-15 Severity: minor If I try to complete a file name before the file is created, once the file is created, trying to complete the file name again displays the name of the file instead of completing it: tty1: $ cat f tty2: $ touch foo tty1: foo $ cat f It would be better if it completed the file name in this case. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311400&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1401] DBTS 100743: inconsistent handling of filename completion wrt colons
Bugs item #311401, was opened at 30/01/2009 10:10 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 100743: inconsistent handling of filename completion wrt colons Distribution: None Originally reported in: Debian BTS Original bug number: 100743 Initial Comment: From: Yann Dirson To: Debian Bug Tracking System Subject: bash: inconsistent handling of filename completion wrt colons Date: Wed, 13 Jun 2001 22:25:56 +0200 Package: bash Version: 2.05-4 Severity: normal `complete-filename' is appently taking `:' as a non-filename-component. `possible-completions' OTOH accepts it as a filename-component char. -> this appears to be inconsistent -> I know that `:' is the separator for *PATH variables, but in those variables only components stating with /, or being just ".", do make sense. I don't see any reason for not activating filename completion when we're not in one of those cases. Not having file completion with colon chars not only causes problems with names of X sockets, but also with the pathnames used by SFS (www.fs.net, and packages sfs-*), which are usually cut'n'pasted and contain colons. Anyway, `:' is definitely not a special char for the shell, despite what I read as argument in one bugreport. It is interpreted specially by a number of programs and library functions, that's all. This is why I'd be in favor of using a new function, named `complete-filename-in-path' or so, and bind it for example to ESC-:, and have complete-filename do what it's name suggests it does. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311401&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1401] DBTS 100743: inconsistent handling of filename completion wrt colons
Bugs item #311401, was opened at 30/01/2009 10:10 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 100743: inconsistent handling of filename completion wrt colons Distribution: None Originally reported in: Debian BTS Original bug number: 100743 Initial Comment: From: Yann Dirson To: Debian Bug Tracking System Subject: bash: inconsistent handling of filename completion wrt colons Date: Wed, 13 Jun 2001 22:25:56 +0200 Package: bash Version: 2.05-4 Severity: normal `complete-filename' is appently taking `:' as a non-filename-component. `possible-completions' OTOH accepts it as a filename-component char. -> this appears to be inconsistent -> I know that `:' is the separator for *PATH variables, but in those variables only components stating with /, or being just ".", do make sense. I don't see any reason for not activating filename completion when we're not in one of those cases. Not having file completion with colon chars not only causes problems with names of X sockets, but also with the pathnames used by SFS (www.fs.net, and packages sfs-*), which are usually cut'n'pasted and contain colons. Anyway, `:' is definitely not a special char for the shell, despite what I read as argument in one bugreport. It is interpreted specially by a number of programs and library functions, that's all. This is why I'd be in favor of using a new function, named `complete-filename-in-path' or so, and bind it for example to ESC-:, and have complete-filename do what it's name suggests it does. -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 10:11 Message: From: Chet Ramey To: d...@debian.org, dir...@debian.org Cc: c...@po.cwru.edu Subject: Debian Bash bug #100743 Date: Tue, 10 Jul 2001 13:23:22 -0400 The bug report says, in part, > `complete-filename' is appently taking `:' as a non-filename-component. > > `possible-completions' OTOH accepts it as a filename-component char. possible-completions does not treat `:' as a filename component character. It acts on exactly the same word as complete-filename. Chet -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311401&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1402] DBTS 501835: check for the use of `uname` within man, apropos, whatis completions
Bugs item #311402, was opened at 30/01/2009 10:13 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 501835: check for the use of `uname` within man, apropos, whatis completions Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 501835 Initial Comment: * Completion for the "man", "apropos", and "whatis" commands depends on a uname of GNU, Linux, Darwin, FreeBSD, SunOS, Cygwin, or OpenBSD. This misses at least NetBSD, if not others. This completion seems applicable to any system which has the appropriate commands. Furthermore, the completion function itself makes assumptions about how to determine manpaths based on a subset of those unames. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311402&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1403] DBTS 501837: don't use uname for pidof compl etion, just check for its presence
Bugs item #311403, was opened at 30/01/2009 10:14 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 501837: don't use uname for pidof completion, just check for its presence Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 501837 Initial Comment: * Completion for the commands pidof, [..] depends on a uname of Linux; however, these commands exist on other systems as well. Checking for the presence of the command seems sufficient. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311403&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1404] DBTS 501838: don't use uname for if{up,d own,status}, just check for their presence
Bugs item #311404, was opened at 30/01/2009 10:15
Status: Open
Priority: 2
Submitted By: David Paleino (hanska-guest)
Assigned to: Nobody (None)
Summary: DBTS 501838: don't use uname for if{up,down,status}, just check for
their presence
Distribution: None
Originally reported in: Debian BTS
Milestone: None
Original bug number: 501838
Initial Comment:
* Completion for the commands [..] ifup, ifdown, and ifstatus
depends on a uname of Linux; however, these commands exist on other
systems as well. Checking for the presence of the command seems
sufficient.
--
You can respond by visiting:
http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311404&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1405] DBTS 501839: don't use uname for iw{config ,list,spy,priv}, just check for their presence
Bugs item #311405, was opened at 30/01/2009 10:16
Status: Open
Priority: 2
Submitted By: David Paleino (hanska-guest)
Assigned to: Nobody (None)
Summary: DBTS 501839: don't use uname for iw{config,list,spy,priv}, just check
for their presence
Distribution: None
Originally reported in: Debian BTS
Milestone: None
Original bug number: 501839
Initial Comment:
* Completion for the commands iwconfig, iwlist, iwspy, iwpriv, [..]
[..] depends on a uname of Linux. While these commands indeed
do run only on Linux, it seems better to simply check for the
commands in question rather than the kernel in use. That way, if
the commands ever run on non-Linux systems, bash-completion will not
need updating. For instance, other systems have a "route" command
which behaves similarly, though I do not know if the existing
completions will work unmodified on it.
--
You can respond by visiting:
http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311405&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1406] DBTS 501840: don't use uname for ipsec, ju st check for its presence
Bugs item #311406, was opened at 30/01/2009 10:17 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 501840: don't use uname for ipsec, just check for its presence Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 501840 Initial Comment: * Completion for the commands [..] ipsec, [..] depends on a uname of Linux. While these commands indeed do run only on Linux, it seems better to simply check for the commands in question rather than the kernel in use. That way, if the commands ever run on non-Linux systems, bash-completion will not need updating. For instance, other systems have a "route" command which behaves similarly, though I do not know if the existing completions will work unmodified on it. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311406&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1407] DBTS 501841: don't use uname for route, ju st check for its presence
Bugs item #311407, was opened at 30/01/2009 10:18 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 501841: don't use uname for route, just check for its presence Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 501841 Initial Comment: * Completion for the commands [..] and route depends on a uname of Linux. While these commands indeed do run only on Linux, it seems better to simply check for the commands in question rather than the kernel in use. That way, if the commands ever run on non-Linux systems, bash-completion will not need updating. For instance, other systems have a "route" command which behaves similarly, though I do not know if the existing completions will work unmodified on it. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311407&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1408] DBTS 501842: complete for 'cc' also on !GN U, !Linux and !Cygwin
Bugs item #311408, was opened at 30/01/2009 10:18 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 501842: complete for 'cc' also on !GNU, !Linux and !Cygwin Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 501842 Initial Comment: * Completion for the various GCC compilers occurs on any system, but only with a uname of GNU, Linux, or Cygwin will bash-completion add those same completions to the "cc" command. bash-completion probably assumes that other systems will not have gcc installed as "cc". -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311408&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1409] DBTS 501843: unused local variable UNAME in _info()
Bugs item #311409, was opened at 30/01/2009 10:19 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 501843: unused local variable UNAME in _info() Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 501843 Initial Comment: * The completion for "info" declares a local variable "UNAME" but never uses it. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311409&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1409] DBTS 501843: unused local variable UNAME in _info()
Bugs item #311409, was opened at 30/01/2009 10:19 >Status: Closed Priority: 2 Submitted By: David Paleino (hanska-guest) >Assigned to: David Paleino (hanska-guest) Summary: DBTS 501843: unused local variable UNAME in _info() Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 501843 Initial Comment: * The completion for "info" declares a local variable "UNAME" but never uses it. -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 10:23 Message: Fixed in r1298. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311409&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1410] ULP 219971: Doesn't handle escaped spaces in /etc/fstab well
Bugs item #311410, was opened at 30/01/2009 10:25 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: ULP 219971: Doesn't handle escaped spaces in /etc/fstab well Distribution: None Originally reported in: Ubuntu Launchpad Milestone: None Original bug number: 219971 Initial Comment: Binary package hint: bash-completion Because of I can't use "/some path" or /some\ path in fstab, I write some\040path as mount point. I write "mount /some" in bash and press Tab, I see "mount /some\\040path" instead of "mount /some\ path" -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311410&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1410] ULP 219971: Doesn't handle escaped spaces in /etc/fstab well
Bugs item #311410, was opened at 30/01/2009 10:25 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: ULP 219971: Doesn't handle escaped spaces in /etc/fstab well Distribution: None Originally reported in: Ubuntu Launchpad Milestone: None Original bug number: 219971 Initial Comment: Binary package hint: bash-completion Because of I can't use "/some path" or /some\ path in fstab, I write some\040path as mount point. I write "mount /some" in bash and press Tab, I see "mount /some\\040path" instead of "mount /some\ path" -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 10:25 Message: DBTS 511149: From: James Westby To: Debian Bug Tracking System Subject: Doesn't handle escaped spaces in /etc/fstab well Date: Wed, 07 Jan 2009 19:35:16 + Package: bash-completion Version: 20080705 Severity: minor Hi, In https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/219971 Danil Ilinykh reported that the handling of escaped spaces in /etc/fstab is not ideal. "Because of I can't use "/some path" or /some\ path in fstab, I write some\040path as mount point. I write "mount /some" in bash and press Tab, I see "mount /some\\040path" instead of "mount /some\ path"" I can verify this behaviour on sid. Thanks, James -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311410&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1411] ULP 254426: Autocomplete of fileames with back quote expansion leaves garbage
Bugs item #311411, was opened at 30/01/2009 10:27 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: ULP 254426: Autocomplete of fileames with backquote expansion leaves garbage Distribution: None Originally reported in: Ubuntu Launchpad Milestone: None Original bug number: 254426 Initial Comment: With Bash programable autocomplete (/etc/bash_completion), commands within backquotes containing a space doesn't get autocompleted properly: $ touch ~/some_file_`date -I`.txt $ ls ~/some_file_`date -I`.txt /home/gaby/some_file_2008-08-03.txt So far this works, but if I press the key at the end of the command: $ ls ~/some_file`date /home/gaby/some_file_2008-08-03.txt The autocompletion doesn't overwrite the whole argument and leaves "~/some_file`date " in front of it. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311411&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1411] ULP 254426: Autocomplete of fileames with back quote expansion leaves garbage
Bugs item #311411, was opened at 30/01/2009 10:27 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: ULP 254426: Autocomplete of fileames with backquote expansion leaves garbage Distribution: None Originally reported in: Ubuntu Launchpad Milestone: None Original bug number: 254426 Initial Comment: With Bash programable autocomplete (/etc/bash_completion), commands within backquotes containing a space doesn't get autocompleted properly: $ touch ~/some_file_`date -I`.txt $ ls ~/some_file_`date -I`.txt /home/gaby/some_file_2008-08-03.txt So far this works, but if I press the key at the end of the command: $ ls ~/some_file`date /home/gaby/some_file_2008-08-03.txt The autocompletion doesn't overwrite the whole argument and leaves "~/some_file`date " in front of it. -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 10:28 Message: DBTS 511151: From: James Westby To: Debian Bug Tracking System Subject: Autocomplete of fileames with backquote expansion leaves garbage Date: Wed, 07 Jan 2009 19:53:22 + Package: bash-completion Version: 20080705 Severity: minor Hi, In https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/254426 "dermoth" reported the following. " With Bash programable autocomplete (/etc/bash_completion), commands within backquotes containing a space doesn't get autocompleted properly: $ touch ~/some_file_`date -I`.txt $ ls ~/some_file_`date -I`.txt /home/gaby/some_file_2008-08-03.txt So far this works, but if I press the key at the end of the command: $ ls ~/some_file`date /home/gaby/some_file_2008-08-03.txt The autocompletion doesn't overwrite the whole argument and leaves "~/some_file`date " in front of it. " Confirmed on sid. Note that you have to have "~" or a directory portion, the bug doesn't happen if you complete a filename in cwd. Thanks, James -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311411&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1412] DBTS 340747: does not show 'make menuconfig ' in kernel tree
Bugs item #311412, was opened at 30/01/2009 10:29 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 340747: does not show 'make menuconfig' in kernel tree Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 340747 Initial Comment: From: Miernik To: Debian Bug Tracking System Subject: bash completion does not show 'make menuconfig' in kernel tree Date: Fri, 25 Nov 2005 16:41:58 +0100 Package: make Version: 3.80-11 Severity: minor While in kernel tree from Debian package linux-source-2.6.14 the followig options are available after make in bash tab completion: czernica:/usr/src/linux-source-2.6.14$ make all checkstack %config cscope depend help modules mrproper prepare prepare2 rpm tags vmlinux archprepare cleanconfigcheck debug_kallsyms distclean includecheck modules_install namespacecheck prepare0 prepare3 scripts/ TAGS buildcheck config crmodverdir dep FORCE kernelreleasemodules_prepare outputmakefile prepare1 prepare-all scripts_basicversioncheck czernica:/usr/src/linux-source-2.6.14$ make There should be 'menuconfig' among these, but there isn't. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311412&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1412] DBTS 340747: does not show 'make menuconfig ' in kernel tree
Bugs item #311412, was opened at 30/01/2009 10:29 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 340747: does not show 'make menuconfig' in kernel tree Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 340747 Initial Comment: From: Miernik To: Debian Bug Tracking System Subject: bash completion does not show 'make menuconfig' in kernel tree Date: Fri, 25 Nov 2005 16:41:58 +0100 Package: make Version: 3.80-11 Severity: minor While in kernel tree from Debian package linux-source-2.6.14 the followig options are available after make in bash tab completion: czernica:/usr/src/linux-source-2.6.14$ make all checkstack %config cscope depend help modules mrproper prepare prepare2 rpm tags vmlinux archprepare cleanconfigcheck debug_kallsyms distclean includecheck modules_install namespacecheck prepare0 prepare3 scripts/ TAGS buildcheck config crmodverdir dep FORCE kernelreleasemodules_prepare outputmakefile prepare1 prepare-all scripts_basicversioncheck czernica:/usr/src/linux-source-2.6.14$ make There should be 'menuconfig' among these, but there isn't. -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 10:29 Message: From: Matthias Klose To: i...@caliban.org, Miernik , 340...@bugs.debian.org Subject: bash completion does not show 'make menuconfig' in kernel tree Date: Sat, 4 Mar 2006 00:29:29 +0100 bash_completion only reads the Makefile, these targets are defined in another file included with the 'include' directive. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311412&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1413] DBTS 330833: Please complete ssh host with { } globbing
Bugs item #311413, was opened at 30/01/2009 10:31
Status: Open
Priority: 2
Submitted By: David Paleino (hanska-guest)
Assigned to: Nobody (None)
Summary: DBTS 330833: Please complete ssh host with {} globbing
Distribution: None
Originally reported in: Debian BTS
Milestone: None
Original bug number: 330833
Initial Comment:
From: Justin Pryzby
To: Debian BTS Submission
Subject: bash: [COMPLETION
Date: Thu, 29 Sep 2005 19:35:49 -0400
Package: bash
Version: 3.0-16
Severity: wishlist
I would like to be able to complete a command like scp a{b,c} j,
but it doesn't presently do anything.. I think the easy solution
would be to make scp accept an arbitrary number of arguments, the
final one being the host (or, possibly, any file OR the host).
--
You can respond by visiting:
http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311413&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1414] DBTS 446355: sudo -e should list filenames ins tead of commands
Bugs item #311414, was opened at 30/01/2009 10:32 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 446355: sudo -e should list filenames instead of commands Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 446355 Initial Comment: From: Matthijs Kooijman To: Debian Bug Tracking System Subject: bash: [COMPLETION] sudo -e should list filenames instead of commands Date: Fri, 12 Oct 2007 15:11:20 +0200 Package: bash Version: 3.1dfsg-8 Severity: wishlist sudo -e allows users to edit files through sudo. So, instead of completing commands, completion should list filenames. Gr. Matthijs -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311414&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1415] DBTS 266967: tab completion for make with impl icit rules
Bugs item #311415, was opened at 30/01/2009 10:34 Status: Open Priority: 2 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 266967: tab completion for make with implicit rules Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 266967 Initial Comment: From: Brian Minton To: Debian Bug Tracking System Subject: bash: tab completion for make with implicit rules Date: Thu, 19 Aug 2004 17:56:49 -0400 Package: bash Version: 3.0-5 Severity: wishlist I made a makefile with some implicit rules, but I can't tab-complete filenames to match it. Here is the makefile (4 lines long): %.html : %.txt pdbtxt2html $< $@ %.txt : %.pdb txt2pdbdoc -d $< $@ So for instance, if I have a file called foo.pdb, and I type: make foo.html I will see the following results: txt2pdbdoc -d foo.pdb foo.txt pdbtxt2html foo.txt foo.html rm foo.txt I would like to be able to do: make fo and see as the possible completions (assuming no other files starting with 'fo'): foo.txt foo.html Built-in implicit rule completion would be nice as well. For instance, having a file called foo.c laying around, I do: make fo and see the following possible completions (again, assuming no other files starting with 'fo' exist): foo foo.o While I am wishing, also completing standard makefile variables would be nice too, like so: make foo CFL would expand to CFLAGS= and then possibly show some of the compiler options by using the cc completions. Similarly, make foo LDF would expand to LDFLAGS= and possibly show some libraries in the library path. thanks, Brian Minton -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311415&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1416] DBTS 309463: completion for /usr/bin/env
Bugs item #311416, was opened at 30/01/2009 10:36 Status: Open Priority: 1 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 309463: completion for /usr/bin/env Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 309463 Initial Comment: From: Tim Connors To: Debian Bug Tracking System Subject: bash: completion for /usr/bin/env Date: Tue, 17 May 2005 22:52:35 +1000 Package: bash Version: 3.0-14 Severity: wishlist Could someone with more familiarity for the completion system please write a completion for env, such that after the blah=foo settings, the command is treated as a meta-command like sudo? Bonus points if it actually works with sudo in front. More bonus points if PATH is already on the env commandline, and the lookup for the meta-command name is done using the new PATH. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311416&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1415] DBTS 266967: tab completion for make with impl icit rules
Bugs item #311415, was opened at 30/01/2009 10:34 Status: Open >Priority: 1 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 266967: tab completion for make with implicit rules Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 266967 Initial Comment: From: Brian Minton To: Debian Bug Tracking System Subject: bash: tab completion for make with implicit rules Date: Thu, 19 Aug 2004 17:56:49 -0400 Package: bash Version: 3.0-5 Severity: wishlist I made a makefile with some implicit rules, but I can't tab-complete filenames to match it. Here is the makefile (4 lines long): %.html : %.txt pdbtxt2html $< $@ %.txt : %.pdb txt2pdbdoc -d $< $@ So for instance, if I have a file called foo.pdb, and I type: make foo.html I will see the following results: txt2pdbdoc -d foo.pdb foo.txt pdbtxt2html foo.txt foo.html rm foo.txt I would like to be able to do: make fo and see as the possible completions (assuming no other files starting with 'fo'): foo.txt foo.html Built-in implicit rule completion would be nice as well. For instance, having a file called foo.c laying around, I do: make fo and see the following possible completions (again, assuming no other files starting with 'fo' exist): foo foo.o While I am wishing, also completing standard makefile variables would be nice too, like so: make foo CFL would expand to CFLAGS= and then possibly show some of the compiler options by using the cc completions. Similarly, make foo LDF would expand to LDFLAGS= and possibly show some libraries in the library path. thanks, Brian Minton -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311415&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1414] DBTS 446355: sudo -e should list filenames ins tead of commands
Bugs item #311414, was opened at 30/01/2009 10:32 Status: Open >Priority: 1 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 446355: sudo -e should list filenames instead of commands Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 446355 Initial Comment: From: Matthijs Kooijman To: Debian Bug Tracking System Subject: bash: [COMPLETION] sudo -e should list filenames instead of commands Date: Fri, 12 Oct 2007 15:11:20 +0200 Package: bash Version: 3.1dfsg-8 Severity: wishlist sudo -e allows users to edit files through sudo. So, instead of completing commands, completion should list filenames. Gr. Matthijs -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311414&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1413] DBTS 330833: Please complete ssh host with { } globbing
Bugs item #311413, was opened at 30/01/2009 10:31
Status: Open
>Priority: 1
Submitted By: David Paleino (hanska-guest)
Assigned to: Nobody (None)
Summary: DBTS 330833: Please complete ssh host with {} globbing
Distribution: None
Originally reported in: Debian BTS
Milestone: None
Original bug number: 330833
Initial Comment:
From: Justin Pryzby
To: Debian BTS Submission
Subject: bash: [COMPLETION
Date: Thu, 29 Sep 2005 19:35:49 -0400
Package: bash
Version: 3.0-16
Severity: wishlist
I would like to be able to complete a command like scp a{b,c} j,
but it doesn't presently do anything.. I think the easy solution
would be to make scp accept an arbitrary number of arguments, the
final one being the host (or, possibly, any file OR the host).
--
You can respond by visiting:
http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311413&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1417] DBTS 360628: Should move ssh completion stuff (etc.) to bash-completion.d/
Bugs item #311417, was opened at 30/01/2009 10:39 Status: Open Priority: 1 Submitted By: David Paleino (hanska-guest) Assigned to: David Paleino (hanska-guest) Summary: DBTS 360628: Should move ssh completion stuff (etc.) to bash-completion.d/ Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 360628 Initial Comment: From: Tuomo Valkonen To: Debian Bug Tracking System Subject: Should move ssh completion stuff (etc.) to bash-completion.d/ Date: Mon, 03 Apr 2006 20:14:34 +0300 Package: bash Version: 3.1-2 Severity: wishlist The ssh completion stuff should be moved from /etc/bash_completion to /etc/bash_completion.d/ssh or something like that. That way I can load those few useful "advanced" completion features from my .bashrc that I want, but skip loading the other annoying completions (the majority of them), that are trying to be too smart. (E.g. refusing to complete .bz2 files after 'tar xzf' causes one to extract an old version of a package and so on.) -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311417&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1417] DBTS 360628: Should move ssh completion stuff (etc.) to bash-completion.d/
Bugs item #311417, was opened at 30/01/2009 10:39 >Status: Closed Priority: 1 Submitted By: David Paleino (hanska-guest) Assigned to: David Paleino (hanska-guest) Summary: DBTS 360628: Should move ssh completion stuff (etc.) to bash-completion.d/ Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 360628 Initial Comment: From: Tuomo Valkonen To: Debian Bug Tracking System Subject: Should move ssh completion stuff (etc.) to bash-completion.d/ Date: Mon, 03 Apr 2006 20:14:34 +0300 Package: bash Version: 3.1-2 Severity: wishlist The ssh completion stuff should be moved from /etc/bash_completion to /etc/bash_completion.d/ssh or something like that. That way I can load those few useful "advanced" completion features from my .bashrc that I want, but skip loading the other annoying completions (the majority of them), that are trying to be too smart. (E.g. refusing to complete .bz2 files after 'tar xzf' causes one to extract an old version of a package and so on.) -- >Comment By: David Paleino (hanska-guest) Date: 30/01/2009 10:40 Message: Fixed in r1189 -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311417&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1418] DBTS 393338: tab completion should show dirs i n blue and executables in green
Bugs item #311418, was opened at 30/01/2009 10:41 Status: Open Priority: 1 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 393338: tab completion should show dirs in blue and executables in green Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 393338 Initial Comment: From: "Jason Spiro" To: sub...@bugs.debian.org Subject: tab completion should show dirs in blue and executables in green Date: Mon, 16 Oct 2006 03:20:59 -0400 Package: bash Version: 3.1-4 Severity: wishlist It would be great if, when I press Tab twice to show the completion preview, bash showed directories in blue and executables in green. Or, alternatively, it would be even better if bash used my full set of color settings which I have set using GNU Dircolors. Cheers, Jason -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311418&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1419] DBTS 489259: completing from local files after redirection ops
Bugs item #311419, was opened at 30/01/2009 10:41 Status: Open Priority: 1 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 489259: completing from local files after redirection ops Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 489259 Initial Comment: From: "Yann Dirson" To: sub...@bugs.debian.org Subject: bash: completing from local files after redirection ops Date: Fri, 4 Jul 2008 15:41:44 +0200 (CEST) Package: bash Version: 3.2-4 Severity: wishlist Tags: bash-completion Completing things like "ssh u...@host tar -zxf - < " should detect the use of redirection operator early, and use file completion instead of requesting a command-specific completion. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311419&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1420] DBTS 511132: completion for mplayer ignores .iso files
Bugs item #311420, was opened at 30/01/2009 10:42 Status: Open Priority: 1 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 511132: completion for mplayer ignores .iso files Distribution: None Originally reported in: Debian BTS Milestone: None Original bug number: 511132 Initial Comment: From: "Laurenz Wiskott" To: "Debian Bug Tracking System" Subject: bash-completion: completion for mplayer ignores .iso files Date: 7 Jan 2009 18:32:34 +0100 Package: bash-completion Version: 20080705 Severity: wishlist It is well possible to run mplayer on .iso files copied from DVDs to the hard disk. However, bash completion ignores .iso files. I suggest to add them. Best wishes, LW. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311420&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1429] Completion for `display' defined twice
Bugs item #311429, was opened at 2009-02-01 21:46 Status: Open Priority: 3 Submitted By: Freddy Vulto (fvu-guest) Assigned to: Nobody (None) Summary: Completion for `display' defined twice Distribution: None Originally reported in: None Milestone: None Original bug number: Initial Comment: There is a specific completion function `_display()' defined for `display' but this is overridden by a complete-by-extension definition for `display'. I think the `_display()' completion is the desired most comprehensive completion. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311429&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1429] Completion for `display' defined twice
Bugs item #311429, was opened at 01/02/2009 21:46 Status: Open Priority: 3 Submitted By: Freddy Vulto (fvu-guest) >Assigned to: Freddy Vulto (fvu-guest) Summary: Completion for `display' defined twice Distribution: None Originally reported in: None Milestone: None Original bug number: Initial Comment: There is a specific completion function `_display()' defined for `display' but this is overridden by a complete-by-extension definition for `display'. I think the `_display()' completion is the desired most comprehensive completion. -- >Comment By: David Paleino (hanska-guest) Date: 01/02/2009 22:29 Message: Bug assigned. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311429&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1429] Completion for `display' defined twice
Bugs item #311429, was opened at 2009-02-01 21:46 Status: Open Priority: 3 Submitted By: Freddy Vulto (fvu-guest) Assigned to: Freddy Vulto (fvu-guest) Summary: Completion for `display' defined twice Distribution: None Originally reported in: None Milestone: None Original bug number: Initial Comment: There is a specific completion function `_display()' defined for `display' but this is overridden by a complete-by-extension definition for `display'. I think the `_display()' completion is the desired most comprehensive completion. -- >Comment By: Freddy Vulto (fvu-guest) Date: 2009-02-01 23:59 Message: - Restored `_display()' completion for `display' by removing completion-by-extension for `display' - Removed duplicate completion option `-borderwidth' for `display' Fixed in r1300. -- Comment By: David Paleino (hanska-guest) Date: 2009-02-01 22:29 Message: Bug assigned. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311429&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1429] Completion for `display' defined twice
Bugs item #311429, was opened at 2009-02-01 21:46 >Status: Closed Priority: 3 Submitted By: Freddy Vulto (fvu-guest) Assigned to: Freddy Vulto (fvu-guest) Summary: Completion for `display' defined twice Distribution: None Originally reported in: None Milestone: None Original bug number: Initial Comment: There is a specific completion function `_display()' defined for `display' but this is overridden by a complete-by-extension definition for `display'. I think the `_display()' completion is the desired most comprehensive completion. -- Comment By: Freddy Vulto (fvu-guest) Date: 2009-02-01 23:59 Message: - Restored `_display()' completion for `display' by removing completion-by-extension for `display' - Removed duplicate completion option `-borderwidth' for `display' Fixed in r1300. -- Comment By: David Paleino (hanska-guest) Date: 2009-02-01 22:29 Message: Bug assigned. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311429&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1429] Completion for `display' defined twice
Bugs item #311429, was opened at 01/02/2009 21:46 Status: Closed Priority: 3 Submitted By: Freddy Vulto (fvu-guest) Assigned to: Freddy Vulto (fvu-guest) Summary: Completion for `display' defined twice Distribution: None Originally reported in: None Milestone: None >Status: Fix Committed Original bug number: Initial Comment: There is a specific completion function `_display()' defined for `display' but this is overridden by a complete-by-extension definition for `display'. I think the `_display()' completion is the desired most comprehensive completion. -- Comment By: Freddy Vulto (fvu-guest) Date: 01/02/2009 23:59 Message: - Restored `_display()' completion for `display' by removing completion-by-extension for `display' - Removed duplicate completion option `-borderwidth' for `display' Fixed in r1300. -- Comment By: David Paleino (hanska-guest) Date: 01/02/2009 22:29 Message: Bug assigned. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311429&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1431] DBTS 489720: please do not expand leading tild es
Bugs item #311431, was opened at 02/02/2009 21:42
Status: Open
Priority: 2
Submitted By: David Paleino (hanska-guest)
Assigned to: David Paleino (hanska-guest)
Summary: DBTS 489720: please do not expand leading tildes
Distribution: None
Originally reported in: Debian BTS
Milestone: None
Status: Accepted
Original bug number: 489720
Initial Comment:
From: Morita Sho
To: Debian Bug Tracking System
Subject: bash-completion: Please do not expand leading tildes
Date: Mon, 07 Jul 2008 20:41:37 +0900
Package: bash-completion
Version: 20080705
Severity: minor
Tags: patch
Hi,
When bash-completion is not installed, the leading tilde will not be
expanded on completion.
$ ls ~testuser/testfile
/home/testuser/testfile
$ ls ~testuser/testf[TAB]
=> ~testuser/testfile
However, when bash-completion is installed, the leading tilde will be
expanded on completion because _expand function performs the tilde
expansion. That is slightly annoying.
$ ls ~testuser/testf[TAB]
=> /home/testuser/testfile
IMHO, the tilde expansion in _expand seems needless because compgen
correctly handles leading tildes.
I suggest following patch.
--- bash_completion.orig2008-07-07 14:07:28.0 +0900
+++ bash_completion 2008-07-07 17:28:59.0 +0900
@@ -353,7 +353,7 @@
# expand ~username type directory specifications
if [[ "$cur" == \~*/* ]]; then
- eval cur=$cur
+ return
elif [[ "$cur" == \~* ]]; then
cur=${cur#\~}
COMPREPLY=( $( compgen -P '~' -u $cur ) )
Regards,
--
You can respond by visiting:
http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311431&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1431] DBTS 489720: please do not expand leading tild es
Bugs item #311431, was opened at 02/02/2009 21:42
>Status: Closed
Priority: 2
Submitted By: David Paleino (hanska-guest)
Assigned to: David Paleino (hanska-guest)
Summary: DBTS 489720: please do not expand leading tildes
Distribution: None
Originally reported in: Debian BTS
Milestone: None
Status: Accepted
Original bug number: 489720
Initial Comment:
From: Morita Sho
To: Debian Bug Tracking System
Subject: bash-completion: Please do not expand leading tildes
Date: Mon, 07 Jul 2008 20:41:37 +0900
Package: bash-completion
Version: 20080705
Severity: minor
Tags: patch
Hi,
When bash-completion is not installed, the leading tilde will not be
expanded on completion.
$ ls ~testuser/testfile
/home/testuser/testfile
$ ls ~testuser/testf[TAB]
=> ~testuser/testfile
However, when bash-completion is installed, the leading tilde will be
expanded on completion because _expand function performs the tilde
expansion. That is slightly annoying.
$ ls ~testuser/testf[TAB]
=> /home/testuser/testfile
IMHO, the tilde expansion in _expand seems needless because compgen
correctly handles leading tildes.
I suggest following patch.
--- bash_completion.orig2008-07-07 14:07:28.0 +0900
+++ bash_completion 2008-07-07 17:28:59.0 +0900
@@ -353,7 +353,7 @@
# expand ~username type directory specifications
if [[ "$cur" == \~*/* ]]; then
- eval cur=$cur
+ return
elif [[ "$cur" == \~* ]]; then
cur=${cur#\~}
COMPREPLY=( $( compgen -P '~' -u $cur ) )
Regards,
--
>Comment By: David Paleino (hanska-guest)
Date: 02/02/2009 21:43
Message:
From: David Paleino
To: 489720-qu...@bugs.debian.org
Cc: Morita Sho , Bash-Completion
Developers
Subject: [RFC] Re: bash-completion: Please do not expand leading tildes
Date: Sat, 6 Sep 2008 16:26:06 +0200
Hi Morita,
Morita Sho wrote:
> When bash-completion is not installed, the leading tilde > will not be
> expanded on completion.
>
> [..]
>
> However, when bash-completion is installed, the leading
> tilde will be expanded on completion because _expand
> function performs the tilde expansion. That is slightly
> annoying.
>
> [..]
>
> IMHO, the tilde expansion in _expand seems needless
> because compgen correctly handles leading tildes.
I agree with you, and have committed the fix (rev1170), but I'm CCing the team
because people might be relying on ~foo being expanded to /home/foo/, and I
don't really know whether this fix might affect other software or not.
However, fix committed. I'll eventually revert it if it causes problems to
other users (i.e. please don't re-file the bug if you see ~foo re-expanded to
/home/foo/ in future versions ;) )
Kindly,
David
--
You can respond by visiting:
http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311431&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1433] /etc/bash_completion.d is being sourced twic e
Bugs item #311433, was opened at 2009-02-04 00:00 >Status: Closed Priority: 3 Submitted By: Freddy Vulto (fvu-guest) Assigned to: Freddy Vulto (fvu-guest) Summary: /etc/bash_completion.d is being sourced twice Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: By default BASH_COMPLETION_DIR and BASH_COMPLETION_COMPAT_DIR contain the same value: BASH_COMPLETION_DIR=/etc/bash_completion.d BASH_COMPLETION_COMPAT_DIR=/etc/bash_completion.d At the end of `bash_completion', both variables are looped through and sourced without checking if the directories are equal, effectively sourcing `/etc/bash_completion.d' twice. -- >Comment By: Freddy Vulto (fvu-guest) Date: 2009-02-04 00:08 Message: Prevent completion dir from being sourced twice if BASH_COMPLETION_DIR and BASH_COMPLETION_COMPAT_DIR are equal. Fixed in r1306. -- Comment By: David Paleino (hanska-guest) Date: 2009-02-04 00:05 Message: I'm really sorry for this, it was kind of a beginning for the new directory layout (COMPAT_DIR is for "compatibility dir"...) Freddy, I will fix this myself if you don't have time. David -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311433&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1433] /etc/bash_completion.d is being sourced twic e
Bugs item #311433, was opened at 2009-02-04 00:00 Status: Open Priority: 3 Submitted By: Freddy Vulto (fvu-guest) Assigned to: Freddy Vulto (fvu-guest) Summary: /etc/bash_completion.d is being sourced twice Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: By default BASH_COMPLETION_DIR and BASH_COMPLETION_COMPAT_DIR contain the same value: BASH_COMPLETION_DIR=/etc/bash_completion.d BASH_COMPLETION_COMPAT_DIR=/etc/bash_completion.d At the end of `bash_completion', both variables are looped through and sourced without checking if the directories are equal, effectively sourcing `/etc/bash_completion.d' twice. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311433&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1433] /etc/bash_completion.d is being sourced twic e
Bugs item #311433, was opened at 04/02/2009 00:00 Status: Open Priority: 3 Submitted By: Freddy Vulto (fvu-guest) Assigned to: Freddy Vulto (fvu-guest) Summary: /etc/bash_completion.d is being sourced twice Distribution: None Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: By default BASH_COMPLETION_DIR and BASH_COMPLETION_COMPAT_DIR contain the same value: BASH_COMPLETION_DIR=/etc/bash_completion.d BASH_COMPLETION_COMPAT_DIR=/etc/bash_completion.d At the end of `bash_completion', both variables are looped through and sourced without checking if the directories are equal, effectively sourcing `/etc/bash_completion.d' twice. -- >Comment By: David Paleino (hanska-guest) Date: 04/02/2009 00:05 Message: I'm really sorry for this, it was kind of a beginning for the new directory layout (COMPAT_DIR is for "compatibility dir"...) Freddy, I will fix this myself if you don't have time. David -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311433&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1385] DBTS 427758: filenames starting with =
Bugs item #311385, was opened at 2009-01-30 10:30 Status: Open Priority: 3 Submitted By: David Paleino (hanska-guest) Assigned to: Nobody (None) Summary: DBTS 427758: filenames starting with = Distribution: None Originally reported in: Debian BTS Milestone: None Status: None Original bug number: 427758 Initial Comment: $ touch =foo $ echo = Expansion results in "=\=foo" rather than "\=foo". -- >Comment By: Ville Skyttä (scop-guest) Date: 2009-02-15 12:21 Message: I'm not sure if "echo" is a good way to test this as it appears no bash_completion code is executed with the reproducers (checked with "set -x"). The odd /tmp vs /tmp/foo behaviour seems to come from bash itself with "echo". On the other hand, with "cat" there are some issues present with the current code in git: $ mkdir /tmp/foo $ cd /tmp $ touch foo/=bar $ cat foo/ $ cat foo/\=bar # ok $ cat foo/= $ cat foo/=foo/\=bar # not ok $ cat foo/=b $ cat foo/=foo/\=bar # not ok -- Comment By: David Paleino (hanska-guest) Date: 2009-01-30 10:32 Message: It doesn't happen anymore with our bzr revision, but still shows a bug: $ mkdir /tmp/foo $ cd /tmp $ touch foo/=bar $ echo foo/= $ echo foo/=bar If there are other files in /tmp/foo/, it behaves oddly: $ touch foo/buz foo/foo $ echo foo/= claws-mail-1000 orbit-neo/ foo/.pcmanfm-socket:0.0-neo gconfd-neo/ serverauth.lwDVrycexY gpg-HiLpT3/ ssh-vyyNyO3687/ .ICE-unix/ .X0-lock liferea.neo.3796948728 .X11-unix/ .lxterminal-socket:0.0-neo $ (i.e. shows files in /tmp/ and not /tmp/foo/) -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311385&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1500] RFE: add okular completion
Bugs item #311500, was opened at 2009-02-23 19:09 Status: Open Priority: 2 Submitted By: Ville Skyttä (scop-guest) Assigned to: Nobody (None) Summary: RFE: add okular completion Distribution: --Distribution-Agnostic-- Originally reported in: Fedora / Red Hat Bugzilla Milestone: None Status: None Original bug number: 486998 Initial Comment: https://bugzilla.redhat.com/486998 "It would be very nice if "okular", the new document-viewing component in KDE4, were included in bash-completion." -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311500&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1500] RFE: add okular completion
Bugs item #311500, was opened at 2009-02-23 19:09 >Status: Closed Priority: 2 Submitted By: Ville Skyttä (scop-guest) >Assigned to: Ville Skyttä (scop-guest) Summary: RFE: add okular completion Distribution: --Distribution-Agnostic-- Originally reported in: Fedora / Red Hat Bugzilla Milestone: None >Status: Fix Committed Original bug number: 486998 Initial Comment: https://bugzilla.redhat.com/486998 "It would be very nice if "okular", the new document-viewing component in KDE4, were included in bash-completion." -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311500&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1510] Add .ape to mplayer supported extensions.
Bugs item #311510, was opened at 2009-02-27 15:26 Status: Open Priority: 3 Submitted By: Santiago Moisés Mola Velasco (coldwind-guest) Assigned to: Nobody (None) Summary: Add .ape to mplayer supported extensions. Distribution: None Originally reported in: None Milestone: 1.0 Status: None Original bug number: Initial Comment: Monkey's Audio (.ape) is supported by mplayer. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311510&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1521] [PATCH] add slash instead of space after dir names in _filedir
Bugs item #311521, was opened at 2009-03-02 16:59 Status: Open Priority: 3 Submitted By: Martin von Gagern (gagern-guest) Assigned to: Nobody (None) Summary: [PATCH] add slash instead of space after dir names in _filedir Distribution: Gentoo Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: I'm unhappy with how completions using _filedir handle directories: they append a space, not a slash. E.g. type "openssl x509 -in /et" and press tab. It will append "c " instead of "c/". Some other completions, e.g. those shipped with subversion, return an empty COMPREPLY in those cases, falling back to default bash completion. As _filedir adds to the list, doesn't claim to provide the whole list all by itself, and seems to have other benefits besides, I fear simply clearing the list won't easily solve all problems. I see no official way to tell bash that a given word is to be treated as a prefix, in order to prevent bash from adding a space. Barring modifications to bash itself, we need some way to trick bash into treating a word as incomplete. E.g. we might add "dir/" and "dir/." to the list of completions, so that "dir/" is the common prefix but not the only possible completion, thus preventing the space. This should only be done for single result tokens, as you would not want such artificial duplicate entries when there are multiple real entries to choose from, possibly displayed to the user in a list. The attached patch against the main git branch addresses this issue. It consists of the following three changes: 1. append / after directory names 2. omit directories from file listings to avoid duplicates 3. add dir/. if the list consists only of a single dir/ entry -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311521&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1521] [PATCH] add slash instead of space after dir names in _filedir
Bugs item #311521, was opened at 2009-03-02 16:59 Status: Open Priority: 3 Submitted By: Martin von Gagern (gagern-guest) Assigned to: Nobody (None) Summary: [PATCH] add slash instead of space after dir names in _filedir Distribution: Gentoo Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: I'm unhappy with how completions using _filedir handle directories: they append a space, not a slash. E.g. type "openssl x509 -in /et" and press tab. It will append "c " instead of "c/". Some other completions, e.g. those shipped with subversion, return an empty COMPREPLY in those cases, falling back to default bash completion. As _filedir adds to the list, doesn't claim to provide the whole list all by itself, and seems to have other benefits besides, I fear simply clearing the list won't easily solve all problems. I see no official way to tell bash that a given word is to be treated as a prefix, in order to prevent bash from adding a space. Barring modifications to bash itself, we need some way to trick bash into treating a word as incomplete. E.g. we might add "dir/" and "dir/." to the list of completions, so that "dir/" is the common prefix but not the only possible completion, thus preventing the space. This should only be done for single result tokens, as you would not want such artificial duplicate entries when there are multiple real entries to choose from, possibly displayed to the user in a list. The attached patch against the main git branch addresses this issue. It consists of the following three changes: 1. append / after directory names 2. omit directories from file listings to avoid duplicates 3. add dir/. if the list consists only of a single dir/ entry -- Comment By: Martin von Gagern (gagern-guest) Date: 2009-03-03 19:27 Message: OK, it's not that easy: with that patch in place, the list of alternatives for e.g. mkdir now lists directories with two slashes. The reason seems to be that the complete command for mkdir (and most other callers of _filedir) contains "-o filenames", while that for openssl (and a few others) does not. Possible solutions: 1. Drop my patch, add -o filenames to affected completions instead. This could cause non-file arguments to be erroneously interpreted as file names. 2. Use my patch, and drom -o filenames from all other affected completions. 3. Provide multiple versions of _filedir and any general purpose function invoking _filedir, like _longopt. I guess I'm in favor of option 2, as this gives the programmatic completion maximal control over the completion process. Once we agree on a solution, I'd write a patch for it as soon as I find the time. While investigating this issue, I also noticed that there exists an option "nospace" to prevent the addition of spaces. This might be the cleaner solution to avoid my "/." hack, but would require modifications to almost all completion functions, in order to provide spaces programmatically. I guess I'd prefer the hack over such a major redesign, at least for now. I've attached a perl script which I've used to investigate the issue. You invoke it using "complete | perl callGraph.pl" from within the directory containing the bash_completion file. It will figure out which functions call which others, and use your current set of completions to list all those that might end up calling _filedir. For each such completion, it lists the completion command (which will give any options) as well as a call graph which might lead to _filedir. Using this tool, you can see which commands will use _filedir and what options are in place for their completions. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311521&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1521] [PATCH] add slash instead of space after dir names in _filedir
Bugs item #311521, was opened at 2009-03-02 18:59 Status: Open Priority: 3 Submitted By: Martin von Gagern (gagern-guest) Assigned to: Nobody (None) Summary: [PATCH] add slash instead of space after dir names in _filedir Distribution: Gentoo Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: I'm unhappy with how completions using _filedir handle directories: they append a space, not a slash. E.g. type "openssl x509 -in /et" and press tab. It will append "c " instead of "c/". Some other completions, e.g. those shipped with subversion, return an empty COMPREPLY in those cases, falling back to default bash completion. As _filedir adds to the list, doesn't claim to provide the whole list all by itself, and seems to have other benefits besides, I fear simply clearing the list won't easily solve all problems. I see no official way to tell bash that a given word is to be treated as a prefix, in order to prevent bash from adding a space. Barring modifications to bash itself, we need some way to trick bash into treating a word as incomplete. E.g. we might add "dir/" and "dir/." to the list of completions, so that "dir/" is the common prefix but not the only possible completion, thus preventing the space. This should only be done for single result tokens, as you would not want such artificial duplicate entries when there are multiple real entries to choose from, possibly displayed to the user in a list. The attached patch against the main git branch addresses this issue. It consists of the following three changes: 1. append / after directory names 2. omit directories from file listings to avoid duplicates 3. add dir/. if the list consists only of a single dir/ entry -- >Comment By: Ville Skyttä (scop-guest) Date: 2009-03-03 22:19 Message: I'd be in favour of 1) (basically s/$default/$filenames/) for consistency. Then, if someone comes up with something definitely better later, do it all over the place in one fell swoop. -- Comment By: Martin von Gagern (gagern-guest) Date: 2009-03-03 21:27 Message: OK, it's not that easy: with that patch in place, the list of alternatives for e.g. mkdir now lists directories with two slashes. The reason seems to be that the complete command for mkdir (and most other callers of _filedir) contains "-o filenames", while that for openssl (and a few others) does not. Possible solutions: 1. Drop my patch, add -o filenames to affected completions instead. This could cause non-file arguments to be erroneously interpreted as file names. 2. Use my patch, and drom -o filenames from all other affected completions. 3. Provide multiple versions of _filedir and any general purpose function invoking _filedir, like _longopt. I guess I'm in favor of option 2, as this gives the programmatic completion maximal control over the completion process. Once we agree on a solution, I'd write a patch for it as soon as I find the time. While investigating this issue, I also noticed that there exists an option "nospace" to prevent the addition of spaces. This might be the cleaner solution to avoid my "/." hack, but would require modifications to almost all completion functions, in order to provide spaces programmatically. I guess I'd prefer the hack over such a major redesign, at least for now. I've attached a perl script which I've used to investigate the issue. You invoke it using "complete | perl callGraph.pl" from within the directory containing the bash_completion file. It will figure out which functions call which others, and use your current set of completions to list all those that might end up calling _filedir. For each such completion, it lists the completion command (which will give any options) as well as a call graph which might lead to _filedir. Using this tool, you can see which commands will use _filedir and what options are in place for their completions. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311521&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1540] add completion for 'screen'
Bugs item #311540, was opened at 13/03/2009 12:08 Status: Open Priority: 3 Submitted By: Simone Fittabile (greeno-guest) Assigned to: Nobody (None) Summary: add completion for 'screen' Distribution: Debian Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: I would like to know if existsted any trick for the GNU screen program. I do not know any: it would be nice to complete screen command line with both a list of names of the started screens and their full identifier (eg. 23442.abcde) The list afaik is gotten through '/bin/screen -l' The completion would result in 'screen 23442.abcde' in case user writes 'screen abc[TAB]' or 'screen 234[TAB]' It be useful to integrate it, would not it? -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311540&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1510] Add .ape to mplayer supported extensions.
Bugs item #311510, was opened at 2009-02-27 17:26 >Status: Closed Priority: 3 Submitted By: Santiago Moisés Mola Velasco (coldwind-guest) Assigned to: Nobody (None) Summary: Add .ape to mplayer supported extensions. Distribution: None Originally reported in: None Milestone: 1.0 >Status: Fix Committed Original bug number: Initial Comment: Monkey's Audio (.ape) is supported by mplayer. -- >Comment By: Ville Skyttä (scop-guest) Date: 2009-03-15 21:59 Message: Applied, thanks. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311510&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1544] quote_readline breaks filenames with spaces co mpletion with bash 4
Bugs item #311544, was opened at 2009-03-15 22:02 Status: Open Priority: 3 Submitted By: Ville Skyttä (scop-guest) Assigned to: Nobody (None) Summary: quote_readline breaks filenames with spaces completion with bash 4 Distribution: None Originally reported in: Fedora / Red Hat Bugzilla Milestone: None Status: None Original bug number: 490322 Initial Comment: quote_readline reportedly breaks completion of filenames with spaces with bash 4. I don't have a bash 4 setup available right now, but more info along with a workaround patch is at https://bugzilla.redhat.com/show_bug.cgi?id=490322 -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311544&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1540] add completion for 'screen'
Bugs item #311540, was opened at 13/03/2009 12:08 Status: Open Priority: 3 Submitted By: Simone Fittabile (greeno-guest) Assigned to: Nobody (None) Summary: add completion for 'screen' Distribution: Debian Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: I would like to know if existsted any trick for the GNU screen program. I do not know any: it would be nice to complete screen command line with both a list of names of the started screens and their full identifier (eg. 23442.abcde) The list afaik is gotten through '/bin/screen -l' The completion would result in 'screen 23442.abcde' in case user writes 'screen abc[TAB]' or 'screen 234[TAB]' It be useful to integrate it, would not it? -- Comment By: Simone Fittabile (greeno-guest) Date: 16/03/2009 17:47 Message: I was wrong, it existed the function to reattach / detach existing screens. The available list is from screen -ls. It currently does not complete the second part of the screen name, eg: for 23442.abcde , only matches for completion the first part of the screen name, i.e. 23442. If even typing abc[TAB] would complete with 23442.abcde I made a patch for this. With it it is possible to only remember begin of the screen name, the completion will take care of the rest. Also fixed with the patch, not completing the possible screen name when -r or -R s not the latest option passed. -- You can respond by visiting: http://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311540&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1544] quote_readline breaks filenames with spaces co mpletion with bash 4
Bugs item #311544, was changed at 2009-03-15 22:02 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311544&group_id=100114 >Status: Closed Priority: 3 Submitted By: Ville Skyttä (scop-guest) Assigned to: Nobody (None) Summary: quote_readline breaks filenames with spaces completion with bash 4 Distribution: None Originally reported in: Fedora / Red Hat Bugzilla Milestone: None Status: Fix Committed Original bug number: 490322 Initial Comment: quote_readline reportedly breaks completion of filenames with spaces with bash 4. I don't have a bash 4 setup available right now, but more info along with a workaround patch is at https://bugzilla.redhat.com/show_bug.cgi?id=490322 -- Comment By: Ville Skyttä (scop-guest) Date: 2009-04-07 21:50 Message: Reportedly fixed by http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=1421e55aac075e13491cd212b796bdd453214a2c This would be a good candidate for the 1.x branch. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311544&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1544] quote_readline breaks filenames with spaces co mpletion with bash 4
Bugs item #311544, was changed at 2009-03-15 22:02 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311544&group_id=100114 Status: Open Priority: 3 Submitted By: Ville Skyttä (scop-guest) Assigned to: Nobody (None) Summary: quote_readline breaks filenames with spaces completion with bash 4 Distribution: None Originally reported in: Fedora / Red Hat Bugzilla Milestone: None >Status: Fix Committed Original bug number: 490322 Initial Comment: quote_readline reportedly breaks completion of filenames with spaces with bash 4. I don't have a bash 4 setup available right now, but more info along with a workaround patch is at https://bugzilla.redhat.com/show_bug.cgi?id=490322 -- >Comment By: Ville Skyttä (scop-guest) Date: 2009-04-07 21:50 Message: Reportedly fixed by http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=1421e55aac075e13491cd212b796bdd453214a2c This would be a good candidate for the 1.x branch. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311544&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was opened at 2009-04-10 22:30 by Olivier Crête You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 Status: Open Priority: 3 Submitted By: Olivier Crête (tester-guest) Assigned to: Nobody (None) Summary: tries to execute ssh UserKnownHostsFile Distribution: Gentoo Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: The _known_hosts function tries to execute the UserKnownHostsFile file instead of just getting its name, there is an extra "eval", if you just remove it, it works fine. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 2009-04-11 05:30 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 Status: Open Priority: 3 Submitted By: Olivier Crête (tester-guest) Assigned to: Nobody (None) Summary: tries to execute ssh UserKnownHostsFile Distribution: Gentoo Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: The _known_hosts function tries to execute the UserKnownHostsFile file instead of just getting its name, there is an extra "eval", if you just remove it, it works fine. -- >Comment By: Ville Skyttä (scop-guest) Date: 2009-04-12 19:47 Message: Which version of bash_completion is this? If not 1.0, please test with it. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 2009-04-10 22:30 by Olivier Crête You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 Status: Open Priority: 3 Submitted By: Olivier Crête (tester-guest) Assigned to: Nobody (None) Summary: tries to execute ssh UserKnownHostsFile Distribution: Gentoo Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: The _known_hosts function tries to execute the UserKnownHostsFile file instead of just getting its name, there is an extra "eval", if you just remove it, it works fine. -- Comment By: Olivier Crête (tester-guest) Date: 2009-04-12 17:03 Message: Its 1.0.. and I also checked the git master (but didn't test it). -- Comment By: Ville Skyttä (scop-guest) Date: 2009-04-12 12:47 Message: Which version of bash_completion is this? If not 1.0, please test with it. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 2009-04-11 05:30 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 Status: Open Priority: 3 Submitted By: Olivier Crête (tester-guest) Assigned to: Nobody (None) Summary: tries to execute ssh UserKnownHostsFile Distribution: Gentoo Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: The _known_hosts function tries to execute the UserKnownHostsFile file instead of just getting its name, there is an extra "eval", if you just remove it, it works fine. -- >Comment By: Ville Skyttä (scop-guest) Date: 2009-04-13 00:40 Message: I can't reproduce - the two eval lines in _known_hosts are both like foo=$( eval echo bar ) which for me does not try to execute "bar". -- Comment By: Olivier Crête (tester-guest) Date: 2009-04-13 00:03 Message: Its 1.0.. and I also checked the git master (but didn't test it). -- Comment By: Ville Skyttä (scop-guest) Date: 2009-04-12 19:47 Message: Which version of bash_completion is this? If not 1.0, please test with it. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 2009-04-10 22:30 by Olivier Crête You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 Status: Open Priority: 3 Submitted By: Olivier Crête (tester-guest) Assigned to: Nobody (None) Summary: tries to execute ssh UserKnownHostsFile Distribution: Gentoo Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: The _known_hosts function tries to execute the UserKnownHostsFile file instead of just getting its name, there is an extra "eval", if you just remove it, it works fine. -- Comment By: Olivier Crête (tester-guest) Date: 2009-04-12 18:07 Message: The difference is that I have two UserKnownHost files in different "Host" sections... So there is a newline in between... Simple example: aa=$(eval echo "$(echo /dev/null; echo /dev/null)") So bashcomp has to be able to deal with multiple answers here, just removing the eval seems to work.. I don't think its required anyway, but maybe I'm missing something (I'm not a bash expert). -- Comment By: Ville Skyttä (scop-guest) Date: 2009-04-12 17:40 Message: I can't reproduce - the two eval lines in _known_hosts are both like foo=$( eval echo bar ) which for me does not try to execute "bar". -- Comment By: Olivier Crête (tester-guest) Date: 2009-04-12 17:03 Message: Its 1.0.. and I also checked the git master (but didn't test it). -- Comment By: Ville Skyttä (scop-guest) Date: 2009-04-12 12:47 Message: Which version of bash_completion is this? If not 1.0, please test with it. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 2009-04-11 05:30 by Ville Skyttä You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 Status: Open Priority: 3 Submitted By: Olivier Crête (tester-guest) >Assigned to: Freddy Vulto (fvu-guest) Summary: tries to execute ssh UserKnownHostsFile Distribution: Gentoo Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: The _known_hosts function tries to execute the UserKnownHostsFile file instead of just getting its name, there is an extra "eval", if you just remove it, it works fine. -- >Comment By: Ville Skyttä (scop-guest) Date: 2009-04-13 12:10 Message: Ok, I can reproduce now. It also appears to work with the eval if the quotes around "$( sed ... )" are removed, but those were added in http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=fec084a69be9383776090df6facfea1a790c5c66 to fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504650 I was not able to reproduce the issue in Debian bug 504650 (works for me both with and without the quotes) but then again it is missing an exact, concrete reproducer so it could be that I'm not testing the right thing. Freddy, David? I'm not sure if the eval is needed either, but someone who understands Debian bug 504650 should check how removing the eval affects the scenario in it. -- Comment By: Olivier Crête (tester-guest) Date: 2009-04-13 01:07 Message: The difference is that I have two UserKnownHost files in different "Host" sections... So there is a newline in between... Simple example: aa=$(eval echo "$(echo /dev/null; echo /dev/null)") So bashcomp has to be able to deal with multiple answers here, just removing the eval seems to work.. I don't think its required anyway, but maybe I'm missing something (I'm not a bash expert). -- Comment By: Ville Skyttä (scop-guest) Date: 2009-04-13 00:40 Message: I can't reproduce - the two eval lines in _known_hosts are both like foo=$( eval echo bar ) which for me does not try to execute "bar". -- Comment By: Olivier Crête (tester-guest) Date: 2009-04-13 00:03 Message: Its 1.0.. and I also checked the git master (but didn't test it). -- Comment By: Ville Skyttä (scop-guest) Date: 2009-04-12 19:47 Message: Which version of bash_completion is this? If not 1.0, please test with it. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 11/04/2009 04:30 by David Paleino You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 >Status: Pending Priority: 3 Submitted By: Olivier Crête (tester-guest) >Assigned to: David Paleino (hanska-guest) Summary: tries to execute ssh UserKnownHostsFile Distribution: Gentoo Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: The _known_hosts function tries to execute the UserKnownHostsFile file instead of just getting its name, there is an extra "eval", if you just remove it, it works fine. -- >Comment By: David Paleino (hanska-guest) Date: 13/04/2009 17:07 Message: Hello, I clearly remember being able to reproduce the bug at the time. However, I'm not able anymore to reproduce it, and Debian #504650 doesn't show up anymore, both with and without quotes. I've been able to reproduce *this* bug (I tried a mixture of this and Debian #504650, i.e. multiple-spaced hosts on more lines) and seems to work without quotes. Also, I believe those two eval's are not needed at all -- and they cause "execution" of specified hostnames. Thus, I'm fixing this bug -- Freddy, if you have more to say, please reopen this bug and feel free to revert my commit (will arrive in the next minutes). Ciao, David -- Comment By: Ville Skyttä (scop-guest) Date: 13/04/2009 11:10 Message: Ok, I can reproduce now. It also appears to work with the eval if the quotes around "$( sed ... )" are removed, but those were added in http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=fec084a69be9383776090df6facfea1a790c5c66 to fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504650 I was not able to reproduce the issue in Debian bug 504650 (works for me both with and without the quotes) but then again it is missing an exact, concrete reproducer so it could be that I'm not testing the right thing. Freddy, David? I'm not sure if the eval is needed either, but someone who understands Debian bug 504650 should check how removing the eval affects the scenario in it. -- Comment By: Olivier Crête (tester-guest) Date: 13/04/2009 00:07 Message: The difference is that I have two UserKnownHost files in different "Host" sections... So there is a newline in between... Simple example: aa=$(eval echo "$(echo /dev/null; echo /dev/null)") So bashcomp has to be able to deal with multiple answers here, just removing the eval seems to work.. I don't think its required anyway, but maybe I'm missing something (I'm not a bash expert). -- Comment By: Ville Skyttä (scop-guest) Date: 12/04/2009 23:40 Message: I can't reproduce - the two eval lines in _known_hosts are both like foo=$( eval echo bar ) which for me does not try to execute "bar". -- Comment By: Olivier Crête (tester-guest) Date: 12/04/2009 23:03 Message: Its 1.0.. and I also checked the git master (but didn't test it). -- Comment By: Ville Skyttä (scop-guest) Date: 12/04/2009 18:47 Message: Which version of bash_completion is this? If not 1.0, please test with it. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1510] Add .ape to mplayer supported extensions.
Bugs item #311510, was changed at 27/02/2009 16:26 by David Paleino You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311510&group_id=100114 Status: Closed Priority: 3 Submitted By: Santiago Moisés Mola Velasco (coldwind-guest) >Assigned to: Ville Skyttä (scop-guest) Summary: Add .ape to mplayer supported extensions. Distribution: None Originally reported in: None Milestone: 1.0 Status: Fix Committed Original bug number: Initial Comment: Monkey's Audio (.ape) is supported by mplayer. -- Comment By: Ville Skyttä (scop-guest) Date: 15/03/2009 20:59 Message: Applied, thanks. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311510&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1544] quote_readline breaks filenames with spaces co mpletion with bash 4
Bugs item #311544, was changed at 15/03/2009 21:02 by David Paleino You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311544&group_id=100114 Status: Closed Priority: 3 Submitted By: Ville Skyttä (scop-guest) >Assigned to: Mike Kelly (pioto-guest) Summary: quote_readline breaks filenames with spaces completion with bash 4 Distribution: None Originally reported in: Fedora / Red Hat Bugzilla >Milestone: 1.1 Status: Fix Committed Original bug number: 490322 Initial Comment: quote_readline reportedly breaks completion of filenames with spaces with bash 4. I don't have a bash 4 setup available right now, but more info along with a workaround patch is at https://bugzilla.redhat.com/show_bug.cgi?id=490322 -- >Comment By: David Paleino (hanska-guest) Date: 13/04/2009 17:14 Message: ACK, setting milestone to 1.1. -- Comment By: Ville Skyttä (scop-guest) Date: 07/04/2009 20:50 Message: Reportedly fixed by http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=1421e55aac075e13491cd212b796bdd453214a2c This would be a good candidate for the 1.x branch. -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311544&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 11/04/2009 04:30 by David Paleino
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114
>Status: Closed
Priority: 3
Submitted By: Olivier Crête (tester-guest)
Assigned to: David Paleino (hanska-guest)
Summary: tries to execute ssh UserKnownHostsFile
Distribution: Gentoo
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
The _known_hosts function tries to execute the UserKnownHostsFile file instead
of just getting its name, there is an extra "eval", if you just remove it, it
works fine.
--
>Comment By: David Paleino (hanska-guest)
Date: 13/04/2009 17:11
Message:
commit a9994ac15f29892a27ebfff6ded63930a43f1187
Author: David Paleino
Date: Mon Apr 13 17:10:41 2009 +0200
Remove eval() and sed quoting in _known_hosts() (Alioth: #311595)
Fixes execution (!!!) of hosts specified by {Global,User}KnownHosts
in SSH config files.
--
Comment By: David Paleino (hanska-guest)
Date: 13/04/2009 17:07
Message:
Hello,
I clearly remember being able to reproduce the bug at the time. However, I'm
not able anymore to reproduce it, and Debian #504650 doesn't show up anymore,
both with and without quotes.
I've been able to reproduce *this* bug (I tried a mixture of this and Debian
#504650, i.e. multiple-spaced hosts on more lines) and seems to work without
quotes.
Also, I believe those two eval's are not needed at all -- and they cause
"execution" of specified hostnames. Thus, I'm fixing this bug -- Freddy, if you
have more to say, please reopen this bug and feel free to revert my commit
(will arrive in the next minutes).
Ciao,
David
--
Comment By: Ville Skyttä (scop-guest)
Date: 13/04/2009 11:10
Message:
Ok, I can reproduce now. It also appears to work with the eval if the quotes
around "$( sed ... )" are removed, but those were added in
http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=fec084a69be9383776090df6facfea1a790c5c66
to fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504650
I was not able to reproduce the issue in Debian bug 504650 (works for me both
with and without the quotes) but then again it is missing an exact, concrete
reproducer so it could be that I'm not testing the right thing. Freddy, David?
I'm not sure if the eval is needed either, but someone who understands Debian
bug 504650 should check how removing the eval affects the scenario in it.
--
Comment By: Olivier Crête (tester-guest)
Date: 13/04/2009 00:07
Message:
The difference is that I have two UserKnownHost files in different "Host"
sections... So there is a newline in between...
Simple example:
aa=$(eval echo "$(echo /dev/null; echo /dev/null)")
So bashcomp has to be able to deal with multiple answers here, just removing
the eval seems to work.. I don't think its required anyway, but maybe I'm
missing something (I'm not a bash expert).
--
Comment By: Ville Skyttä (scop-guest)
Date: 12/04/2009 23:40
Message:
I can't reproduce - the two eval lines in _known_hosts are both like
foo=$( eval echo bar )
which for me does not try to execute "bar".
--
Comment By: Olivier Crête (tester-guest)
Date: 12/04/2009 23:03
Message:
Its 1.0.. and I also checked the git master (but didn't test it).
--
Comment By: Ville Skyttä (scop-guest)
Date: 12/04/2009 18:47
Message:
Which version of bash_completion is this? If not 1.0, please test with it.
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1420] DBTS 511132: completion for mplayer ignores .iso files
Bugs item #311420, was changed at 30/01/2009 10:42 by David Paleino
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311420&group_id=100114
>Status: Pending
Priority: 1
Submitted By: David Paleino (hanska-guest)
>Assigned to: David Paleino (hanska-guest)
Summary: DBTS 511132: completion for mplayer ignores .iso files
Distribution: None
Originally reported in: Debian BTS
>Milestone: 1.1
>Status: Accepted
Original bug number: 511132
Initial Comment:
From: "Laurenz Wiskott"
To: "Debian Bug Tracking System"
Subject: bash-completion: completion for mplayer ignores .iso files
Date: 7 Jan 2009 18:32:34 +0100
Package: bash-completion
Version: 20080705
Severity: wishlist
It is well possible to run mplayer on .iso files copied from DVDs to the
hard disk. However, bash completion ignores .iso files. I suggest to add
them.
Best wishes, LW.
--
>Comment By: David Paleino (hanska-guest)
Date: 13/04/2009 17:47
Message:
Hello *,
regarding this bug, I have only one available solution: using just _filedir. In
fact:
1) if we use _filedir '@([Ii][Ss][Oo])', we should also call _filedir later to
show /dev/devices to pass to mplayer;
2) if we do some hack (I tried this), like first calling 1), then using
cur=${cur:=/dev/} and then _filedir, we're failing too, since we're overwriting
$cur (while the user most probably wants to see just "foo.iso" and "/dev/*" in
his completion)
3) if we override $cur with "/dev/" if it begins with @(/|/d|/de|/dev),
otherwise complete on .iso, we kinda have this functionality -- but the user
doesn't have completion for .isos in directories starting with "/dev";
4) if we keep like it is now (see contrib/mplayer), we're clearly missing a
functionality.
I was forgetting, seems like the .iso files are only recognized by the
-dvd-device option (taken from the manpage): if anyone knows of any other use,
we should fix that too :)
I'm attaching a possible patch for this (point 3, actually), would you please
comment on this?
Kindly,
David
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311420&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1420] DBTS 511132: completion for mplayer ignores .iso files
Bugs item #311420, was changed at 30/01/2009 10:42 by David Paleino
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311420&group_id=100114
>Status: Open
Priority: 1
Submitted By: David Paleino (hanska-guest)
Assigned to: David Paleino (hanska-guest)
Summary: DBTS 511132: completion for mplayer ignores .iso files
Distribution: None
Originally reported in: Debian BTS
Milestone: 1.1
Status: Accepted
Original bug number: 511132
Initial Comment:
From: "Laurenz Wiskott"
To: "Debian Bug Tracking System"
Subject: bash-completion: completion for mplayer ignores .iso files
Date: 7 Jan 2009 18:32:34 +0100
Package: bash-completion
Version: 20080705
Severity: wishlist
It is well possible to run mplayer on .iso files copied from DVDs to the
hard disk. However, bash completion ignores .iso files. I suggest to add
them.
Best wishes, LW.
--
Comment By: David Paleino (hanska-guest)
Date: 13/04/2009 17:47
Message:
Hello *,
regarding this bug, I have only one available solution: using just _filedir. In
fact:
1) if we use _filedir '@([Ii][Ss][Oo])', we should also call _filedir later to
show /dev/devices to pass to mplayer;
2) if we do some hack (I tried this), like first calling 1), then using
cur=${cur:=/dev/} and then _filedir, we're failing too, since we're overwriting
$cur (while the user most probably wants to see just "foo.iso" and "/dev/*" in
his completion)
3) if we override $cur with "/dev/" if it begins with @(/|/d|/de|/dev),
otherwise complete on .iso, we kinda have this functionality -- but the user
doesn't have completion for .isos in directories starting with "/dev";
4) if we keep like it is now (see contrib/mplayer), we're clearly missing a
functionality.
I was forgetting, seems like the .iso files are only recognized by the
-dvd-device option (taken from the manpage): if anyone knows of any other use,
we should fix that too :)
I'm attaching a possible patch for this (point 3, actually), would you please
comment on this?
Kindly,
David
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311420&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 2009-04-11 04:30 by Freddy Vulto
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114
Status: Closed
Priority: 3
Submitted By: Olivier Crête (tester-guest)
Assigned to: David Paleino (hanska-guest)
Summary: tries to execute ssh UserKnownHostsFile
Distribution: Gentoo
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
The _known_hosts function tries to execute the UserKnownHostsFile file instead
of just getting its name, there is an extra "eval", if you just remove it, it
works fine.
--
>Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-13 23:17
Message:
The quote around the sed output is still necessary if we want to support the
`known_hosts' files containing whitespace, for example with this ssh config:
UserKnownHostsFile "known hosts1" # Contains TWO spaces
UserKnownHostsFile "known hosts2" # Contains TWO spaces
So I'm adding the quotes again around the sed output since removing 'eval'
alone already fixes the execution(!!!) :-(
$ echo $( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )
"known hosts1" "known hosts2"
$ echo "$( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )"
"known hosts1"
"known hosts2"
A TODO is to make ssh completion actually handle the case of more than one
specified UserKnownHostsFile (didn't even know it was supported by ssh):
`user_kh' and `global_kh' have to become arrays.
So we have to watch for all `eval echo'-s then? There's an "eval echo" in the
`dequote()' function too. We have to make sure all parameters to `dequote' are
quoted (as is done in _ssh()), otherwise there's potentially the same
problem(?):
$ dequote "$'foo\nbar'"
foo
bar
$ dequote $'foo\nbar'
foo
bash: bar: command not found
Regards,
Freddy Vulto
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 17:11
Message:
commit a9994ac15f29892a27ebfff6ded63930a43f1187
Author: David Paleino
Date: Mon Apr 13 17:10:41 2009 +0200
Remove eval() and sed quoting in _known_hosts() (Alioth: #311595)
Fixes execution (!!!) of hosts specified by {Global,User}KnownHosts
in SSH config files.
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 17:07
Message:
Hello,
I clearly remember being able to reproduce the bug at the time. However, I'm
not able anymore to reproduce it, and Debian #504650 doesn't show up anymore,
both with and without quotes.
I've been able to reproduce *this* bug (I tried a mixture of this and Debian
#504650, i.e. multiple-spaced hosts on more lines) and seems to work without
quotes.
Also, I believe those two eval's are not needed at all -- and they cause
"execution" of specified hostnames. Thus, I'm fixing this bug -- Freddy, if you
have more to say, please reopen this bug and feel free to revert my commit
(will arrive in the next minutes).
Ciao,
David
--
Comment By: Ville Skyttä (scop-guest)
Date: 2009-04-13 11:10
Message:
Ok, I can reproduce now. It also appears to work with the eval if the quotes
around "$( sed ... )" are removed, but those were added in
http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=fec084a69be9383776090df6facfea1a790c5c66
to fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504650
I was not able to reproduce the issue in Debian bug 504650 (works for me both
with and without the quotes) but then again it is missing an exact, concrete
reproducer so it could be that I'm not testing the right thing. Freddy, David?
I'm not sure if the eval is needed either, but someone who understands Debian
bug 504650 should check how removing the eval affects the scenario in it.
--
Comment By: Olivier Crête (tester-guest)
Date: 2009-04-13 00:07
Message:
The difference is that I have two UserKnownHost files in different "Host"
sections... So there is a newline in between...
Simple example:
aa=$(eval echo "$(echo /dev/null; echo /dev/null)")
So bashcomp has to be able to deal with multiple answers here, just removing
the eval seems to work.. I don't think its required anyway, but maybe I'm
missing something (I'm not a bash expert).
--
Comment By: Ville Skyttä (scop-guest)
Date: 2009-04-12 23:40
Message:
I can't reproduce - the two eval lines in _known_hosts are both like
foo=$( eval echo bar )
which for me does not try to execute "bar".
--
Comment By:
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 2009-04-11 04:30 by Freddy Vulto
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114
Status: Closed
Priority: 3
Submitted By: Olivier Crête (tester-guest)
Assigned to: David Paleino (hanska-guest)
Summary: tries to execute ssh UserKnownHostsFile
Distribution: Gentoo
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
The _known_hosts function tries to execute the UserKnownHostsFile file instead
of just getting its name, there is an extra "eval", if you just remove it, it
works fine.
--
>Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-13 23:35
Message:
The `eval' is/was used - and is still necessary - to remove possible quotes
around the UserKnownHostsFiles... ("known hosts{1,2}" in my previous message).
Maybe we should remove these quotes with parameter expansion instead of 'eval'
then?
--
Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-13 23:17
Message:
The quote around the sed output is still necessary if we want to support the
`known_hosts' files containing whitespace, for example with this ssh config:
UserKnownHostsFile "known hosts1" # Contains TWO spaces
UserKnownHostsFile "known hosts2" # Contains TWO spaces
So I'm adding the quotes again around the sed output since removing 'eval'
alone already fixes the execution(!!!) :-(
$ echo $( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )
"known hosts1" "known hosts2"
$ echo "$( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )"
"known hosts1"
"known hosts2"
A TODO is to make ssh completion actually handle the case of more than one
specified UserKnownHostsFile (didn't even know it was supported by ssh):
`user_kh' and `global_kh' have to become arrays.
So we have to watch for all `eval echo'-s then? There's an "eval echo" in the
`dequote()' function too. We have to make sure all parameters to `dequote' are
quoted (as is done in _ssh()), otherwise there's potentially the same
problem(?):
$ dequote "$'foo\nbar'"
foo
bar
$ dequote $'foo\nbar'
foo
bash: bar: command not found
Regards,
Freddy Vulto
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 17:11
Message:
commit a9994ac15f29892a27ebfff6ded63930a43f1187
Author: David Paleino
Date: Mon Apr 13 17:10:41 2009 +0200
Remove eval() and sed quoting in _known_hosts() (Alioth: #311595)
Fixes execution (!!!) of hosts specified by {Global,User}KnownHosts
in SSH config files.
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 17:07
Message:
Hello,
I clearly remember being able to reproduce the bug at the time. However, I'm
not able anymore to reproduce it, and Debian #504650 doesn't show up anymore,
both with and without quotes.
I've been able to reproduce *this* bug (I tried a mixture of this and Debian
#504650, i.e. multiple-spaced hosts on more lines) and seems to work without
quotes.
Also, I believe those two eval's are not needed at all -- and they cause
"execution" of specified hostnames. Thus, I'm fixing this bug -- Freddy, if you
have more to say, please reopen this bug and feel free to revert my commit
(will arrive in the next minutes).
Ciao,
David
--
Comment By: Ville Skyttä (scop-guest)
Date: 2009-04-13 11:10
Message:
Ok, I can reproduce now. It also appears to work with the eval if the quotes
around "$( sed ... )" are removed, but those were added in
http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=fec084a69be9383776090df6facfea1a790c5c66
to fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504650
I was not able to reproduce the issue in Debian bug 504650 (works for me both
with and without the quotes) but then again it is missing an exact, concrete
reproducer so it could be that I'm not testing the right thing. Freddy, David?
I'm not sure if the eval is needed either, but someone who understands Debian
bug 504650 should check how removing the eval affects the scenario in it.
--
Comment By: Olivier Crête (tester-guest)
Date: 2009-04-13 00:07
Message:
The difference is that I have two UserKnownHost files in different "Host"
sections... So there is a newline in between...
Simple example:
aa=$(eval echo "$(echo /dev/null; echo /dev/null)")
So bashcomp has to be able to deal with multiple answers here, just removing
the eval seems to work.. I don't think its required anyway, but maybe I'm
missing something (I'm no
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 11/04/2009 04:30 by David Paleino
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114
>Status: Open
Priority: 3
Submitted By: Olivier Crête (tester-guest)
Assigned to: David Paleino (hanska-guest)
Summary: tries to execute ssh UserKnownHostsFile
Distribution: Gentoo
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
The _known_hosts function tries to execute the UserKnownHostsFile file instead
of just getting its name, there is an extra "eval", if you just remove it, it
works fine.
--
>Comment By: David Paleino (hanska-guest)
Date: 13/04/2009 23:45
Message:
Aha, maybe re-reading the bugreport I didn't fully understand it. Yes, the
quotes are really needed. However, what's the probability of having parameter
expansion inside ~/.ssh/config (or whatever)?
Freddy, feel free to reassign this bug to yourself if you wish. In the
meanwhile, I'm reopening it.
--
Comment By: Freddy Vulto (fvu-guest)
Date: 13/04/2009 23:35
Message:
The `eval' is/was used - and is still necessary - to remove possible quotes
around the UserKnownHostsFiles... ("known hosts{1,2}" in my previous message).
Maybe we should remove these quotes with parameter expansion instead of 'eval'
then?
--
Comment By: Freddy Vulto (fvu-guest)
Date: 13/04/2009 23:17
Message:
The quote around the sed output is still necessary if we want to support the
`known_hosts' files containing whitespace, for example with this ssh config:
UserKnownHostsFile "known hosts1" # Contains TWO spaces
UserKnownHostsFile "known hosts2" # Contains TWO spaces
So I'm adding the quotes again around the sed output since removing 'eval'
alone already fixes the execution(!!!) :-(
$ echo $( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )
"known hosts1" "known hosts2"
$ echo "$( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )"
"known hosts1"
"known hosts2"
A TODO is to make ssh completion actually handle the case of more than one
specified UserKnownHostsFile (didn't even know it was supported by ssh):
`user_kh' and `global_kh' have to become arrays.
So we have to watch for all `eval echo'-s then? There's an "eval echo" in the
`dequote()' function too. We have to make sure all parameters to `dequote' are
quoted (as is done in _ssh()), otherwise there's potentially the same
problem(?):
$ dequote "$'foo\nbar'"
foo
bar
$ dequote $'foo\nbar'
foo
bash: bar: command not found
Regards,
Freddy Vulto
--
Comment By: David Paleino (hanska-guest)
Date: 13/04/2009 17:11
Message:
commit a9994ac15f29892a27ebfff6ded63930a43f1187
Author: David Paleino
Date: Mon Apr 13 17:10:41 2009 +0200
Remove eval() and sed quoting in _known_hosts() (Alioth: #311595)
Fixes execution (!!!) of hosts specified by {Global,User}KnownHosts
in SSH config files.
--
Comment By: David Paleino (hanska-guest)
Date: 13/04/2009 17:07
Message:
Hello,
I clearly remember being able to reproduce the bug at the time. However, I'm
not able anymore to reproduce it, and Debian #504650 doesn't show up anymore,
both with and without quotes.
I've been able to reproduce *this* bug (I tried a mixture of this and Debian
#504650, i.e. multiple-spaced hosts on more lines) and seems to work without
quotes.
Also, I believe those two eval's are not needed at all -- and they cause
"execution" of specified hostnames. Thus, I'm fixing this bug -- Freddy, if you
have more to say, please reopen this bug and feel free to revert my commit
(will arrive in the next minutes).
Ciao,
David
--
Comment By: Ville Skyttä (scop-guest)
Date: 13/04/2009 11:10
Message:
Ok, I can reproduce now. It also appears to work with the eval if the quotes
around "$( sed ... )" are removed, but those were added in
http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=fec084a69be9383776090df6facfea1a790c5c66
to fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504650
I was not able to reproduce the issue in Debian bug 504650 (works for me both
with and without the quotes) but then again it is missing an exact, concrete
reproducer so it could be that I'm not testing the right thing. Freddy, David?
I'm not sure if the eval is needed either, but someone who understands Debian
bug 504650 should check how removing the eval affects the scenario in it.
--
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 2009-04-11 04:30 by Freddy Vulto
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114
Status: Open
Priority: 3
Submitted By: Olivier Crête (tester-guest)
>Assigned to: Freddy Vulto (fvu-guest)
Summary: tries to execute ssh UserKnownHostsFile
Distribution: Gentoo
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
The _known_hosts function tries to execute the UserKnownHostsFile file instead
of just getting its name, there is an extra "eval", if you just remove it, it
works fine.
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 23:45
Message:
Aha, maybe re-reading the bugreport I didn't fully understand it. Yes, the
quotes are really needed. However, what's the probability of having parameter
expansion inside ~/.ssh/config (or whatever)?
Freddy, feel free to reassign this bug to yourself if you wish. In the
meanwhile, I'm reopening it.
--
Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-13 23:35
Message:
The `eval' is/was used - and is still necessary - to remove possible quotes
around the UserKnownHostsFiles... ("known hosts{1,2}" in my previous message).
Maybe we should remove these quotes with parameter expansion instead of 'eval'
then?
--
Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-13 23:17
Message:
The quote around the sed output is still necessary if we want to support the
`known_hosts' files containing whitespace, for example with this ssh config:
UserKnownHostsFile "known hosts1" # Contains TWO spaces
UserKnownHostsFile "known hosts2" # Contains TWO spaces
So I'm adding the quotes again around the sed output since removing 'eval'
alone already fixes the execution(!!!) :-(
$ echo $( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )
"known hosts1" "known hosts2"
$ echo "$( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )"
"known hosts1"
"known hosts2"
A TODO is to make ssh completion actually handle the case of more than one
specified UserKnownHostsFile (didn't even know it was supported by ssh):
`user_kh' and `global_kh' have to become arrays.
So we have to watch for all `eval echo'-s then? There's an "eval echo" in the
`dequote()' function too. We have to make sure all parameters to `dequote' are
quoted (as is done in _ssh()), otherwise there's potentially the same
problem(?):
$ dequote "$'foo\nbar'"
foo
bar
$ dequote $'foo\nbar'
foo
bash: bar: command not found
Regards,
Freddy Vulto
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 17:11
Message:
commit a9994ac15f29892a27ebfff6ded63930a43f1187
Author: David Paleino
Date: Mon Apr 13 17:10:41 2009 +0200
Remove eval() and sed quoting in _known_hosts() (Alioth: #311595)
Fixes execution (!!!) of hosts specified by {Global,User}KnownHosts
in SSH config files.
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 17:07
Message:
Hello,
I clearly remember being able to reproduce the bug at the time. However, I'm
not able anymore to reproduce it, and Debian #504650 doesn't show up anymore,
both with and without quotes.
I've been able to reproduce *this* bug (I tried a mixture of this and Debian
#504650, i.e. multiple-spaced hosts on more lines) and seems to work without
quotes.
Also, I believe those two eval's are not needed at all -- and they cause
"execution" of specified hostnames. Thus, I'm fixing this bug -- Freddy, if you
have more to say, please reopen this bug and feel free to revert my commit
(will arrive in the next minutes).
Ciao,
David
--
Comment By: Ville Skyttä (scop-guest)
Date: 2009-04-13 11:10
Message:
Ok, I can reproduce now. It also appears to work with the eval if the quotes
around "$( sed ... )" are removed, but those were added in
http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=fec084a69be9383776090df6facfea1a790c5c66
to fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504650
I was not able to reproduce the issue in Debian bug 504650 (works for me both
with and without the quotes) but then again it is missing an exact, concrete
reproducer so it could be that I'm not testing the right thing. Freddy, David?
I'm not sure if the eval is needed either, but someone who understands Debian
bug 504650 should check how removing the eval affects the scenario in it.
--
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 11/04/2009 04:30 by David Paleino
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114
Status: Open
Priority: 3
Submitted By: Olivier Crête (tester-guest)
Assigned to: Freddy Vulto (fvu-guest)
Summary: tries to execute ssh UserKnownHostsFile
Distribution: Gentoo
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
The _known_hosts function tries to execute the UserKnownHostsFile file instead
of just getting its name, there is an extra "eval", if you just remove it, it
works fine.
--
>Comment By: David Paleino (hanska-guest)
Date: 15/04/2009 14:40
Message:
A Debian user reported this bug too, and he attached a patch. Freddy, since
you've reassigned the bug to yourself, would you mind taking a look?
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=support_multiple_hosts_files.patch;att=1;bug=524190
David
--
Comment By: David Paleino (hanska-guest)
Date: 13/04/2009 23:45
Message:
Aha, maybe re-reading the bugreport I didn't fully understand it. Yes, the
quotes are really needed. However, what's the probability of having parameter
expansion inside ~/.ssh/config (or whatever)?
Freddy, feel free to reassign this bug to yourself if you wish. In the
meanwhile, I'm reopening it.
--
Comment By: Freddy Vulto (fvu-guest)
Date: 13/04/2009 23:35
Message:
The `eval' is/was used - and is still necessary - to remove possible quotes
around the UserKnownHostsFiles... ("known hosts{1,2}" in my previous message).
Maybe we should remove these quotes with parameter expansion instead of 'eval'
then?
--
Comment By: Freddy Vulto (fvu-guest)
Date: 13/04/2009 23:17
Message:
The quote around the sed output is still necessary if we want to support the
`known_hosts' files containing whitespace, for example with this ssh config:
UserKnownHostsFile "known hosts1" # Contains TWO spaces
UserKnownHostsFile "known hosts2" # Contains TWO spaces
So I'm adding the quotes again around the sed output since removing 'eval'
alone already fixes the execution(!!!) :-(
$ echo $( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )
"known hosts1" "known hosts2"
$ echo "$( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )"
"known hosts1"
"known hosts2"
A TODO is to make ssh completion actually handle the case of more than one
specified UserKnownHostsFile (didn't even know it was supported by ssh):
`user_kh' and `global_kh' have to become arrays.
So we have to watch for all `eval echo'-s then? There's an "eval echo" in the
`dequote()' function too. We have to make sure all parameters to `dequote' are
quoted (as is done in _ssh()), otherwise there's potentially the same
problem(?):
$ dequote "$'foo\nbar'"
foo
bar
$ dequote $'foo\nbar'
foo
bash: bar: command not found
Regards,
Freddy Vulto
--
Comment By: David Paleino (hanska-guest)
Date: 13/04/2009 17:11
Message:
commit a9994ac15f29892a27ebfff6ded63930a43f1187
Author: David Paleino
Date: Mon Apr 13 17:10:41 2009 +0200
Remove eval() and sed quoting in _known_hosts() (Alioth: #311595)
Fixes execution (!!!) of hosts specified by {Global,User}KnownHosts
in SSH config files.
--
Comment By: David Paleino (hanska-guest)
Date: 13/04/2009 17:07
Message:
Hello,
I clearly remember being able to reproduce the bug at the time. However, I'm
not able anymore to reproduce it, and Debian #504650 doesn't show up anymore,
both with and without quotes.
I've been able to reproduce *this* bug (I tried a mixture of this and Debian
#504650, i.e. multiple-spaced hosts on more lines) and seems to work without
quotes.
Also, I believe those two eval's are not needed at all -- and they cause
"execution" of specified hostnames. Thus, I'm fixing this bug -- Freddy, if you
have more to say, please reopen this bug and feel free to revert my commit
(will arrive in the next minutes).
Ciao,
David
--
Comment By: Ville Skyttä (scop-guest)
Date: 13/04/2009 11:10
Message:
Ok, I can reproduce now. It also appears to work with the eval if the quotes
around "$( sed ... )" are removed, but those were added in
http://git.debian.org/?p=bash-completion/bash-completion.git;a=commitdiff;h=fec084a69be9383776090df6facfea1a790c5c66
to fix http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504650
I was not able to reproduce the issue in Debian bu
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 2009-04-11 04:30 by Freddy Vulto
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114
Status: Open
Priority: 3
Submitted By: Olivier Crête (tester-guest)
Assigned to: Freddy Vulto (fvu-guest)
Summary: tries to execute ssh UserKnownHostsFile
Distribution: Gentoo
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
The _known_hosts function tries to execute the UserKnownHostsFile file instead
of just getting its name, there is an extra "eval", if you just remove it, it
works fine.
--
>Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-16 23:04
Message:
Patch looks good, I'll apply.
Since the patch already uses parameter expansion to remove double quotes, the
`eval' can be removed as well.
Single quotes aren't allowed around a UserKnownHostsFile parameter (tested on
OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007) so removing the
double quotes should be enough.
Theoretically, a specified UserKnownHostsFile could contain double quotes. So
an improvement still would be to really dequote instead of search-replacing all
quotes. An improved `dequote()' should do without `eval' and instead accept an
additional parameter $2:
---8< (pseudocode) -
# $1 mixed Param to dequote
# $2 integer Quotes to remove:
# 0 (default) Remove single or double quotes
# 1 Remove single quotes
# 2 Remove double quotes
dequote() {
if (($2 == 0/1) && ($1 =~ "[\s]'$1'[\s]")) {
trim whitespace & remove single quotes
} elseif (($2 == 0/2) && ($1 =~ '[\s]"$1"[\s]')) {
trim whitespace & remove double quotes
fi
}
---8<---
Freddy
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-15 14:40
Message:
A Debian user reported this bug too, and he attached a patch. Freddy, since
you've reassigned the bug to yourself, would you mind taking a look?
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=support_multiple_hosts_files.patch;att=1;bug=524190
David
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 23:45
Message:
Aha, maybe re-reading the bugreport I didn't fully understand it. Yes, the
quotes are really needed. However, what's the probability of having parameter
expansion inside ~/.ssh/config (or whatever)?
Freddy, feel free to reassign this bug to yourself if you wish. In the
meanwhile, I'm reopening it.
--
Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-13 23:35
Message:
The `eval' is/was used - and is still necessary - to remove possible quotes
around the UserKnownHostsFiles... ("known hosts{1,2}" in my previous message).
Maybe we should remove these quotes with parameter expansion instead of 'eval'
then?
--
Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-13 23:17
Message:
The quote around the sed output is still necessary if we want to support the
`known_hosts' files containing whitespace, for example with this ssh config:
UserKnownHostsFile "known hosts1" # Contains TWO spaces
UserKnownHostsFile "known hosts2" # Contains TWO spaces
So I'm adding the quotes again around the sed output since removing 'eval'
alone already fixes the execution(!!!) :-(
$ echo $( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )
"known hosts1" "known hosts2"
$ echo "$( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )"
"known hosts1"
"known hosts2"
A TODO is to make ssh completion actually handle the case of more than one
specified UserKnownHostsFile (didn't even know it was supported by ssh):
`user_kh' and `global_kh' have to become arrays.
So we have to watch for all `eval echo'-s then? There's an "eval echo" in the
`dequote()' function too. We have to make sure all parameters to `dequote' are
quoted (as is done in _ssh()), otherwise there's potentially the same
problem(?):
$ dequote "$'foo\nbar'"
foo
bar
$ dequote $'foo\nbar'
foo
bash: bar: command not found
Regards,
Freddy Vulto
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 17:11
Message:
commit a9994ac15f29892a27ebfff6ded63930a43f1187
Author: David Paleino
Date: Mon Apr 13 17:10:41 2009 +0200
Remove eval() and sed quoting in _known_hosts() (Alioth: #311595)
Fixes execution (!!!) of hosts specified by {Global,User}KnownHosts
in SSH config f
[Bash-completion-devel] [bash-completion-Bugs][31 1595] tries to execute ssh UserKnownHostsFile
Bugs item #311595, was changed at 2009-04-11 04:30 by Freddy Vulto
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311595&group_id=100114
>Status: Closed
Priority: 3
Submitted By: Olivier Crête (tester-guest)
Assigned to: Freddy Vulto (fvu-guest)
Summary: tries to execute ssh UserKnownHostsFile
Distribution: Gentoo
Originally reported in: None
Milestone: None
Status: None
Original bug number:
Initial Comment:
The _known_hosts function tries to execute the UserKnownHostsFile file instead
of just getting its name, there is an extra "eval", if you just remove it, it
works fine.
--
Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-16 23:04
Message:
Patch looks good, I'll apply.
Since the patch already uses parameter expansion to remove double quotes, the
`eval' can be removed as well.
Single quotes aren't allowed around a UserKnownHostsFile parameter (tested on
OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007) so removing the
double quotes should be enough.
Theoretically, a specified UserKnownHostsFile could contain double quotes. So
an improvement still would be to really dequote instead of search-replacing all
quotes. An improved `dequote()' should do without `eval' and instead accept an
additional parameter $2:
---8< (pseudocode) -
# $1 mixed Param to dequote
# $2 integer Quotes to remove:
# 0 (default) Remove single or double quotes
# 1 Remove single quotes
# 2 Remove double quotes
dequote() {
if (($2 == 0/1) && ($1 =~ "[\s]'$1'[\s]")) {
trim whitespace & remove single quotes
} elseif (($2 == 0/2) && ($1 =~ '[\s]"$1"[\s]')) {
trim whitespace & remove double quotes
fi
}
---8<---
Freddy
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-15 14:40
Message:
A Debian user reported this bug too, and he attached a patch. Freddy, since
you've reassigned the bug to yourself, would you mind taking a look?
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=support_multiple_hosts_files.patch;att=1;bug=524190
David
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 23:45
Message:
Aha, maybe re-reading the bugreport I didn't fully understand it. Yes, the
quotes are really needed. However, what's the probability of having parameter
expansion inside ~/.ssh/config (or whatever)?
Freddy, feel free to reassign this bug to yourself if you wish. In the
meanwhile, I'm reopening it.
--
Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-13 23:35
Message:
The `eval' is/was used - and is still necessary - to remove possible quotes
around the UserKnownHostsFiles... ("known hosts{1,2}" in my previous message).
Maybe we should remove these quotes with parameter expansion instead of 'eval'
then?
--
Comment By: Freddy Vulto (fvu-guest)
Date: 2009-04-13 23:17
Message:
The quote around the sed output is still necessary if we want to support the
`known_hosts' files containing whitespace, for example with this ssh config:
UserKnownHostsFile "known hosts1" # Contains TWO spaces
UserKnownHostsFile "known hosts2" # Contains TWO spaces
So I'm adding the quotes again around the sed output since removing 'eval'
alone already fixes the execution(!!!) :-(
$ echo $( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )
"known hosts1" "known hosts2"
$ echo "$( sed -ne 's/^[ \t]*UserKnownHostsFile['"$'\t '"']*\(.*\)$/\1/p'
config )"
"known hosts1"
"known hosts2"
A TODO is to make ssh completion actually handle the case of more than one
specified UserKnownHostsFile (didn't even know it was supported by ssh):
`user_kh' and `global_kh' have to become arrays.
So we have to watch for all `eval echo'-s then? There's an "eval echo" in the
`dequote()' function too. We have to make sure all parameters to `dequote' are
quoted (as is done in _ssh()), otherwise there's potentially the same
problem(?):
$ dequote "$'foo\nbar'"
foo
bar
$ dequote $'foo\nbar'
foo
bash: bar: command not found
Regards,
Freddy Vulto
--
Comment By: David Paleino (hanska-guest)
Date: 2009-04-13 17:11
Message:
commit a9994ac15f29892a27ebfff6ded63930a43f1187
Author: David Paleino
Date: Mon Apr 13 17:10:41 2009 +0200
Remove eval() and sed quoting in _known_hosts() (Alioth: #311595)
Fixes execution (!!!) of hosts specified by {Global,User}KnownHosts
in SSH config
[Bash-completion-devel] [bash-completion-Bugs][31 1613] tar completion with xz
Bugs item #311613, was opened at 2009-04-22 12:55 by Eric Blake You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311613&group_id=100114 Status: Open Priority: 3 Submitted By: Eric Blake (eblake-guest) Assigned to: Nobody (None) Summary: tar completion with xz Distribution: --Distribution-Agnostic-- Originally reported in: None Milestone: None Status: None Original bug number: Initial Comment: I noticed that tar completion in 1.0 finally supports lzma files. However, tar 1.22 changed -J from lzma over to xz (xz is the replacement for lzma, which understands the obsolete .lzma file format but also the new .xz file format). This part of _tar: *[J]*f) ext='t?(ar.)lz?(ma)'; regex='t\(ar\.\)\?lzma\?' should probably be rewritten: *[J]*f) ext='t?(ar.)[lx]z?(ma)'; regex='t\(ar\.\)\?[xl]z\(ma\?\)?' -- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311613&group_id=100114 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] [bash-completion-Bugs][31 1614] quoting bug in _known_hosts
Bugs item #311614, was opened at 2009-04-22 13:00 by Eric Blake
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311614&group_id=100114
Status: Open
Priority: 3
Submitted By: Eric Blake (eblake-guest)
Assigned to: Nobody (None)
Summary: quoting bug in _known_hosts
Distribution: --Distribution-Agnostic--
Originally reported in: None
Milestone: 1.0
Status: None
Original bug number:
Initial Comment:
There is a quoting bug in _known_hosts, which causes the shell to attempt glob
expansion. Although unlikely, a user can name a file to include shell
metacharacters so that the glob performs arbitrary actions.
This portion of _known_hosts:
COMPREPLY=($( awk 'BEGIN {FS=","}
/^\s*[^|\#]/ {for (i=1; i<=2; ++i) { \
gsub(" .*$", "", $i); \
if ($i ~ /'$cur'/) {print $i} \
}}' "${...@]}" 2>/dev/null ));
Needs "" around $cur. Otherwise, something like 'ssh ' causes cur to be
defined as [a-z.], and since $cur does not occur in "", the shell treats it as
a glob.
--
You can respond by visiting:
https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=311614&group_id=100114
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
