On Wed, Feb 23, 2022 at 03:37:12PM -0500, Chet Ramey wrote:
> As others have noted, bash-completion is a separate package.
> But we might be able to figure out where it's not being appropriately
> quoted if you enable `set -x' before attempting the completion. At
> least
On 2/23/22 11:34 AM, Ian! D. Allen wrote:
> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
>
> Description:
> BASH completion cannot correctly handle file names containing newline
> characters.
As others have noted, bash-completion is a separate pack
On Wed, 23 Feb 2022 11:34:52 -0500
"Ian! D. Allen" wrote:
> # Now, load the completion scripts and watch it break:
> bash-5.0$ source /usr/share/bash-completion/bash_completion
Issues regarding completion scripts should be reported to their respective
author
> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
>
> Description:
> BASH completion cannot correctly handle file names containing
> newline characters.
>
> Repeat-By:
> # First, get a shell with no completion loaded and show it working:
>
Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.0
> Patch Level: 17
> Release Status: release
>
> Description:
> BASH completion cannot correctly handle file names containing
> newline characters.
>
> Repeat-By:
> # First, get a shell with no
output: Linux ubuntu20-04 5.13.0-30-generic #33~20.04.1-Ubuntu SMP Mon
Feb 7 14:25:10 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 17
Release Status: release
Description:
BASH completion cannot correctly handle file names
On 7/2/21 2:13 AM, Phi Debian wrote:
Thanx Chet for taking time to explain.
May be readline API should have a way to know that a quote ['"`] is opened
ine many previous lines and the first occurence of such quote ine the
current one , is a closing one.
There might be a way to do it using the
Thanx Chet for taking time to explain.
May be readline API should have a way to know that a quote ['"`] is opened
ine many previous lines and the first occurence of such quote ine the
current one , is a closing one.
Well I guess this is too much of a trouble for something living this way
for such
On 6/22/21 3:52 AM, Phi Debian wrote:
When doing
$ echo foo "bar" /tm
I got /tm expanded to /tmp/ that is indeed correct.
But if I do
$ echo foo "bar
more bar" /tm
No completion is done. My question is doest this behavior a feature or a
bug?
Neither, really, it's just a consequence of rea
May be posting a link is not appropriate so I cut/paste it here
I bumped into this problem regarding bash completion, can't find reference
to it.
When doing
$ echo foo "bar" /tm
I got /tm expanded to /tmp/ that is indeed correct.
But if I do
$ echo foo "bar
more bar&qu
Hi All,
I posted a question to STKO and someone suggest I should open a 'feature
request' here.
https://stackoverflow.com/questions/68065039/bash-completion-after-a-multiline-string
Thanx in advance,
Phi
Hello Chet,
it turns out, that https://salsa.debian.org/debian/bash-completion is copied
from
https://github.com/scop/bash-completion/ , so please include the latter in the
documentation.
Regards
Дилян
On Fri, 2019-04-12 at 15:32 -0400, Chet Ramey wrote:
> On 4/11/19 6:00 PM, Ди
On 4/11/19 6:00 PM, Дилян Палаузов wrote:
> Hello,
>
> as alioth.debian.or is down, replace at
> https://www.gnu.org/software/bash/manual/html_node/A-Programmable-Completion-Example.html
> the reference from http://bash-completion.alioth.debian.org/ to
> https://salsa.debi
Hello,
as alioth.debian.or is down, replace at
https://www.gnu.org/software/bash/manual/html_node/A-Programmable-Completion-Example.html
the reference from http://bash-completion.alioth.debian.org/ to
https://salsa.debian.org/debian/bash-completion .
Regards
Дилян
On 3/26/19 3:43 AM, d3fault wrote:
> Bash Version: 4.4
> Patch Level: 12
> Release Status: release
>
> Description:
> In the following example it auto-completes without putting double
> quotes around "hi mom", which means a process would see it as 2
> separate args instead of 1.
If you wan
From: d3fault
To: bug-bash@gnu.org,b...@packages.debian.org
Subject: bash completion of an option with a space in it, isn't double quoted
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM=
On 2/25/18 5:01 AM, Budi wrote:
> How to apply Bash completion in more useful way.
> If TAB key is pressed Bash just show a list of corresponding command, I
> thought it will scroll over all corresponding command on which the cursor
> of shell prompt is active. (just like traditional
How to apply Bash completion in more useful way.
If TAB key is pressed Bash just show a list of corresponding command, I
thought it will scroll over all corresponding command on which the cursor
of shell prompt is active. (just like traditional Windows cmd prompt)
How to make it able to perform
On 2/20/18 3:15 PM, Justin Pryzby wrote:
> Bash Version: 4.1
> Patch Level: 2
> Release Status: release
>
> Description:
> SIGABRT during readline completion.
>
> Repeat-By:
> Unable to reproduce
It's likely that this has been fixed in the eight years since bash-4.1 was
released
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
The title says it all.
Example:
get_completion "git a"
> add
> am
> annotate
> apply
> archive
get_completion "ls --a"
> --all
> --almost-all
> --author
There are various attempts to do it online, the most complete seems to be:
https://brbsix.github.io/2015/11/29/accessing-tab-completion-progr
On 8/22/16 9:43 AM, Jaro Punta wrote:
> I am not sure this is a bug but I cannot find an explanation why this
> happens. Sometimes when I execute certain commands, and I press the
> Tab key while I am typing the command, then after the commands
> finishes, the terminal is left in a abnormal state (
I am not sure this is a bug but I cannot find an explanation why this
happens. Sometimes when I execute certain commands, and I press the
Tab key while I am typing the command, then after the commands
finishes, the terminal is left in a abnormal state (e.g. terminal echo
is off). This seems to happ
have this:
> db.rc \$home/Downloads/games/DOS/Captain\ Bible\ in\ the\ Dome\ of\
> Darkness.zip
> Notice the dollar sign which is now erroneously escaped (home is a variable).
This is a case for which you need to enable the `direxpand' option. You've
presented the bash co
> for example I have this in shell input:
> db.rc $home/Downloads/games/DOS/Captai
> and after I press Tab I have this:
> db.rc \$home/Downloads/games/DOS/Captain\ Bible\ in\ the\ Dome\ of\
> Darkness.zip
Sorry, the completed command line was wrapped:
db.rc \$home/Downloads/games/DOS/Captain\
Hi,
I use bash 4.3.039 and there is a bug (not necessarily a recent
regression) with its file name completion feature.
for example I have this in shell input:
db.rc $home/Downloads/games/DOS/Captai
and after I press Tab I have this:
db.rc \$home/Downloads/games/DOS/Captain\ Bible\ in\ the\ Dom
On Fri, 10 Jul 2015 16:33:34 -0400
Chet Ramey wrote:
> Perfect, thanks. Try the attached patch.
Yep, fixes the bug. Thanks!
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgp7AW88NhmiX.pgp
Description: OpenPGP digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/10/15 4:15 PM, Hanno Böck wrote:
> On Fri, 10 Jul 2015 16:00:25 -0400
> Chet Ramey wrote:
>
>> That helps, but they are strings, so can you print the string
>> values? I'm interested in reproducing this instead of just guessing
>> and not being
On Fri, 10 Jul 2015 16:00:25 -0400
Chet Ramey wrote:
> That helps, but they are strings, so can you print the string
> values? I'm interested in reproducing this instead of just guessing
> and not being able to fix it at an appropriately high level. Thanks.
pathname /
x */
temp /
--
Hanno Bö
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/10/15 3:42 PM, Hanno Böck wrote:
> On Fri, 10 Jul 2015 15:34:02 -0400
> Chet Ramey wrote:
>
>>> Here's the asan message on 4.4 alpha:
>>> ==5999==ERROR: AddressSanitizer: heap-buffer-overflow on address
>>> 0x602000
>> 002d6f at pc 0x5ca2b8 bp 0
On Fri, 10 Jul 2015 15:34:02 -0400
Chet Ramey wrote:
> > Here's the asan message on 4.4 alpha:
> > ==5999==ERROR: AddressSanitizer: heap-buffer-overflow on address
> > 0x602000
> 002d6f at pc 0x5ca2b8 bp 0x7fffc9d75240 sp 0x7fffc9d75230
> > READ of size 1 at 0x60202d6f thread T0
> > #0 0x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/10/15 2:38 PM, Hanno Böck wrote:
> Hi Chet,
>
> On Fri, 10 Jul 2015 14:23:25 -0400
> Chet Ramey wrote:
>
>>> To reproduce:
>>> a) compile bash with CFLAGS="-fsanitize=address -g"
>>> b) type in a=/ a
>>> c) go back with the cursor behind the ba
On Fri, 10 Jul 2015 14:41:04 -0400
Chet Ramey wrote:
> On 7/10/15 2:38 PM, Hanno Böck wrote:
> > On Fri, 10 Jul 2015 14:23:25 -0400
> > Chet Ramey wrote:
> >
> >>> To reproduce:
> >>> a) compile bash with CFLAGS="-fsanitize=address -g"
> >>> b) type in a=/ a
> >>> c) go back with the cursor beh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/10/15 2:38 PM, Hanno Böck wrote:
> Hi Chet,
>
> On Fri, 10 Jul 2015 14:23:25 -0400
> Chet Ramey wrote:
>
>>> To reproduce:
>>> a) compile bash with CFLAGS="-fsanitize=address -g"
>>> b) type in a=/ a
>>> c) go back with the cursor behind the ba
Hi Chet,
On Fri, 10 Jul 2015 14:23:25 -0400
Chet Ramey wrote:
> > To reproduce:
> > a) compile bash with CFLAGS="-fsanitize=address -g"
> > b) type in a=/ a
> > c) go back with the cursor behind the backslash and press tab
>
> Thanks for the report. I've attached a patch that should address th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/6/15 6:46 PM, Hanno Böck wrote:
> Hi,
>
> With Address Sanitizer I discovered another out of bounds read issue in
> bash. This is different from the issue I recently reported here and
> for which Chet already provided a patch:
> https://lists.gnu
Hi,
With Address Sanitizer I discovered another out of bounds read issue in
bash. This is different from the issue I recently reported here and
for which Chet already provided a patch:
https://lists.gnu.org/archive/html/bug-bash/2015-06/msg00089.html
To reproduce:
a) compile bash with CFLAGS="-fs
ard this discussion, I thought -- it's a matter
of preference, though I think I prefer expansion, I could see times
when it might be a hassle (if the var was a REAL long expansion,
it might overflow the line)...but having it not work at all...
That's not useful for anyone.
And to be complete,
Eric Blake wrote:
On 06/07/2012 03:22 PM, Linda Walsh wrote:
This isn't a matter of preference... its a real bug.
Ex:
$ ls $HOME/bin
"ls: cannot access $HOME/bin: No such file or directory"
Yes, we know. Ergo patch 29:
According to the the referred to discussion on this
issu
On 06/07/2012 03:22 PM, Linda Walsh wrote:
> This isn't a matter of preference... its a real bug.
>
> Ex:
> $ ls $HOME/bin
> "ls: cannot access $HOME/bin: No such file or directory"
Yes, we know. Ergo patch 29:
https://lists.gnu.org/archive/html/bug-bash/2012-05/msg00148.html
--
Eric Blake
Clark WANG wrote:
On Mon, May 28, 2012 at 11:32 PM, John E. Malmberg wrote:
Actual results:
ls \$HOME/
Already discussed for quite a few times. :) For example:
http://lists.gnu.org/archive/html/bug-bash/2011-12/msg00079.html
(patched attached)
http://lists.gnu.org/archive/html/bug-bash/201
On Tue, May 29, 2012 at 8:34 AM, John E. Malmberg wrote:
>
> On this platform, file names with $ in them tend to show up as they have
> special meaning.
>
> BASH-4.2$ echo *\$*
> GNV$BASH.DSF GNV$BASH.EXE GNV$BASH.MAP GNV$SHELL.C_FIRST GNV$VERSION.C_FIRST
> gnv$bash_startup.com gnv$main_wrapper gn
On 5/29/12 8:34 AM, John E. Malmberg wrote:
> In the discussion that you referenced earlier, it mentions that it was
> considered making this behavior controlled by a settable parameter.
>
> Is that implemented with this patch?
>
> Is this eventually going to be part of an official patch?
Yes a
On 5/29/2012 7:12 AM, Chet Ramey wrote:
On 5/28/12 11:32 AM, John E. Malmberg wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=825751
bash-4.2.24-1.fc16.i686
Please take a look at
http://git.savannah.gnu.org/cgit/bash.git/log/?h=direxpand
and see if that behaves the way you like.
Thanks,
On 5/28/12 11:32 AM, John E. Malmberg wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=825751
>
> bash-4.2.24-1.fc16.i686
Please take a look at
http://git.savannah.gnu.org/cgit/bash.git/log/?h=direxpand
and see if that behaves the way you like.
Chet
--
``The lyf so short, the craft so long
On Mon, May 28, 2012 at 11:32 PM, John E. Malmberg wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=825751
>
> bash-4.2.24-1.fc16.i686
>
> Steps to Reproduce:
> 1. Activate a terminal running a bash shell
> 2. ls $HOME/
> 3.
>
> Actual results:
> ls \$HOME/
Already discussed for quite a few t
https://bugzilla.redhat.com/show_bug.cgi?id=825751
bash-4.2.24-1.fc16.i686
Steps to Reproduce:
1. Activate a terminal running a bash shell
2. ls $HOME/
3.
Actual results:
ls \$HOME/
I get the directory get expanded result on Bash 1.4.8 (VMS special
build) and on Bash 3.2.25(1)-release.
Rega
Hi,
I don't know if this is a know issue. It probably is, because I'm not
a bash-completion long-time user:
$ tar Jxvf pkg/mpfr-3.1.0.tar.xz -C -srbash: compgen: -r: invalid option
compgen: usage: compgen [-abcdefgjksuv] [-o option] [-A action] [-G
globpat] [-W wordlist] [-F fun
Chris F.A. Johnson wrote:
>I can confirm it on 3.05b, 3.0 and 4.2:
>
> while [ ${n:=0} -lt 5 ]
> do
> se
>
> All I get is a beep.
Hmm... It is still completing. But not command completion. It is
doing filename completion instead of command completion. It is out of
sync with the current
On Sat, 5 Nov 2011, Bob Proulx wrote:
Peng Yu wrote:
Current, bash doesn't do command completion between do and done (for loop).
I'm wondering if this feature can be added.
Of course bash does do command completion between do and done. Can
you give an exact example test case? On what versio
Peng Yu wrote:
> Current, bash doesn't do command completion between do and done (for loop).
> I'm wondering if this feature can be added.
Of course bash does do command completion between do and done. Can
you give an exact example test case? On what version of bash?
Bob
Hi,
Current, bash doesn't do command completion between do and done (for loop).
I'm wondering if this feature can be added.
--
Regards,
Peng
Le mardi 09 août 2011 à 10:05 +0800, Clark J. Wang a écrit :
> On Sun, Aug 7, 2011 at 11:35 PM, jonathan MERCIER
> wrote:
> I have a bash completion file (see below)
> It works fine, but i would like add a feature => not expand
> the flag by
>
On Sun, Aug 7, 2011 at 11:35 PM, jonathan MERCIER
wrote:
> I have a bash completion file (see below)
> It works fine, but i would like add a feature => not expand the flag by
> a space when it contain '='
> curently when i do:
> $ ldc2 -Df
> ldc2 -Df=⊔
> i
I have a bash completion file (see below)
It works fine, but i would like add a feature => not expand the flag by
a space when it contain '='
curently when i do:
$ ldc2 -Df
ldc2 -Df=⊔
i would like:
ldc2 -Df
ldc2 -Df=
without space
tanks a lot
---
# bash completion
> On Sat, Feb 05, 2011 at 01:58:39PM -0600, Dennis Williamson wrote:
>On Sat, Feb 5, 2011 at 1:35 PM, Roger wrote:
>> When using bash completion on files within local folder, ie. "$ ls f"
>> showing results for files starting with char "f" -- or any char(
On Sat, Feb 5, 2011 at 1:35 PM, Roger wrote:
> When using bash completion on files within local folder, ie. "$ ls f"
> showing results for files starting with char "f" -- or any char(s) you may
> specify, results are not provided in color when bash, terminal and
When using bash completion on files within local folder, ie. "$ ls f"
showing results for files starting with char "f" -- or any char(s) you may
specify, results are not provided in color when bash, terminal and ls are
configured for using color.
I do believe, results for bash
Hello,
I'm trying to figure out how to get more of the readline granularity
in the bash completion process.
First of all I would like to fprintf to rl_outstream before
display_matches and from what I saw readline defines a
rl_completion_display_matches_hook which doesn't seem used by bas
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: darwin8.11.0
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc' -
DCONF_OSTYPE='darwin8.11.0' -DCONF_MACHTYPE='powerpc-apple-
darwin8.11.0' -DCONF_VENDOR='apple' -DLOCALEDIR='/usr/
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/
Eric Blake wrote:
This was originally reported on the cygwin lists; it is still present in
stock bash 3.2.33.
This has already been fixed for the next version.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Live Strong. No day but today.
Chet Ramey
Chris F.A. Johnson wrote:
>> bash-3.2$ ./x/ < tab after x now adds slash
>>
>> Once the shell starts doing this, it keeps doing it. Restarting bash
>> solves the problem.
>
>I don't see that problem, and I'm using the same version of
>bash.
I can reproduce it, s
On 2008-03-13, Eric Blake wrote:
>
> This was originally reported on the cygwin lists; it is still present in
> stock bash 3.2.33.
>
> - -
>
> From: David Rothenberger
> Subject: Problem with bash completion
>
> Sometimes bash gets confused and starts adding a sl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This was originally reported on the cygwin lists; it is still present in
stock bash 3.2.33.
- -
From: David Rothenberger
Subject: Problem with bash completion
Sometimes bash gets confused and starts adding a slash at the end of
files when I do
i use Arch GNU/Linux and BASH is my login shell. i have also installed
"bash_completion" package but sometimes BASH tab-completion works and
sometimes not. most of the times the BASH tab-completion doe snot work
and just throws the frustrating beep on me (form my cabinet). at the
same time ZSH has
n the method:
>
> _cd()
> {
> local IFS=$'\t\n' cur=${COMP_WORDS[COMP_CWORD]} i j k
> [...]
> }
I should mention I posted here since my mail to Ian, the bash
completion maintainer, bounced. Anyone knows how to reach him?
--
Benjamin Rutt
__
I have an animated gif that shows the bug. If you browse to:
http://bmi.osu.edu/~rutt/bashcompletion.gif
it will show how e.g.
cd $HOM
will expand to
cd \$HOME
I think this is a bug in the method:
_cd()
{
local IFS=$'\t\n' cur=${COMP_WORDS[COMP_CWORD]} i j k
[...]
}
My version is
> First I did this: complete -W "p3 p2 p1" mycommand
>
> Then I of course tested it by typing: mycommand p
>
> Now when I push tab button it offers first "p1", then "p2" .. in
> "alpabetical"
> order. However it would be nice if I could make complete to honor the order
> in the word list.
>
Hi,
I have a problem with bash programmable completion.
First I did this: complete -W "p3 p2 p1" mycommand
Then I of course tested it by typing: mycommand p
Now when I push tab button it offers first "p1", then "p2" .. in "alpabetical"
order. However it would be nice if I could make complete
> -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -march=i586
> -mcpu=i686 -fmessage-length=0 -Wall -g -D_GNU_SOURCE -Wall -pipe -g
> -fbranch-probabilities
> uname output: Linux cboltz 2.6.11.4-21.7-default #1 Thu Jun 2 14:23:14
> UTC 2005 i686 i686 i386 GNU/Linu
cpu=i686 -fmessage-length=0 -Wall -g -D_GNU_SOURCE -Wall -pipe -g
-fbranch-probabilities
uname output: Linux cboltz 2.6.11.4-21.7-default #1 Thu Jun 2 14:23:14
UTC 2005 i686 i686 i386 GNU/Linux
Machine Type: i586-suse-linux
Bash Version: 3.0
Patch Level: 16
Release Status: release
Description:
Bash c
> Why not just add a mount for C: as /c?
>
> That's what I did, so now I can move around with ease, with the same
> number of characters to have to type as c:
Hm, yes that is a nice alternate solution. Thanks for the idea!
___
Bug-bash mailing list
B
Gary Fritz <[EMAIL PROTECTED]> writes:
> In
> http://groups-
> beta.google.com/group/gnu.bash.bug/browse_thread/thread/e0dc6716afe8162d/df
> a06fd85db708e1
> a bug was reported that prevented TAB completion from working properly in
> Cygwin when the "c:/" synonym for "/cygdrive/c" was used. Beca
Chet Ramey <[EMAIL PROTECTED]> wrote:
> The fix, available in the current release of bash, is to modify the
> contents of the COMP_WORDBREAKS variable to remove the `:'.
Outstanding!! Exactly what I needed. Thanks!
Gary
___
Bug-bash mailing list
Bug
Gary Fritz wrote:
> In
> http://groups-
> beta.google.com/group/gnu.bash.bug/browse_thread/thread/e0dc6716afe8162d/df
> a06fd85db708e1
> a bug was reported that prevented TAB completion from working properly in
> Cygwin when the "c:/" synonym for "/cygdrive/c" was used. Because ":" is
> consider
In
http://groups-
beta.google.com/group/gnu.bash.bug/browse_thread/thread/e0dc6716afe8162d/df
a06fd85db708e1
a bug was reported that prevented TAB completion from working properly in
Cygwin when the "c:/" synonym for "/cygdrive/c" was used. Because ":" is
considered whitespace for completion for
77 matches
Mail list logo
