Red-Hat Bug 825751 - bash-completion fails on environment variables

[John E. Malmberg]

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/<TAB>
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.

Regards,
-John

[Clark WANG]

On Mon, May 28, 2012 at 11:32 PM, John E. Malmberg <wb8...@qsl.net> 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/<TAB>
> 3.
>
> 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/2011-12/msg00035.html

[Chet Ramey]

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 to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/

[John E. Malmberg]

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,

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?

This issue was reported to me by the same person that submitted the
Red-Hat Bug report, and not something that is directly impacting me.

I did search for the issue before posting, but apparently did not use
the right keywords, and I did not see the issue addressed in any of the
official patches.

In my current spare time project below, I am planning to try to just
implement as much as the current Bash + official patch behavior as I
can, and probably not implement the optional patches. Once I get the
base 4.2 release functional, then I will apply all the official patches
to the source.

LION> bash --version
GNU bash, version 4.2.0(1)-release (ia64-dec-vms)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
GNV-2.1-3-JEM-2 May 12 2012 19:36:33

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
gnv$vms_main_link.exe

Regards,
-John

[Chet Ramey]

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 and yes and sooner rather than later.

[DJ Mills]

On Tue, May 29, 2012 at 8:34 AM, John E. Malmberg <wb8...@qsl.net> 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 gnv$vms_main_link.exe
>
> Regards,
> -John
>

Pathname expansion doesn't perform any escaping... this is a
completely separate thing from the readline tab completion issue.

touch 'foo bar' 'baz blah'; echo *\ *
baz blah foo bar

echo takes its arguments and concatenates them with spaces... using
printf can show that they're properly escaped.
touch 'foo bar' 'baz blah'; printf '<%s> ' *\ *; echo
<baz blah> <foo bar>

[Linda Walsh]

Clark WANG wrote:

> On Mon, May 28, 2012 at 11:32 PM, John E. Malmberg <wb8...@qsl.net> 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/2011-12/msg00035.html

-----
In reading the messages quoted above, I'm not sure some people
understand the severity of the bug.

This isn't a matter of preference... its a real bug.

Ex:
$ ls $HOME/bin<TAB><RETURN>
"ls: cannot access $HOME/bin: No such file or directory"

It's not about expansion or non-expansion during the editing phase--
that would be a matter of preference, it's that when you hit enter,
it doesn't expand the variables -- which I can't see being useful for
anyone.

Note -- this is the same type of problem as Bash not correcting
the case of path components.

Bash isn't correcting the lines anymore so that final
expansions match real paths...


When I originally heard 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.

[Eric Blake]

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<TAB><RETURN>
> "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 ebl...@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[Linda Walsh]

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<TAB><RETURN>
>> "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
issue, this was first claimed to be a problem in Feb 2011 --
um... 16 months ago...

Good to see you had a full grasp of the problem
and that it only took you 16 months to come up with a patch...

[Roman Rakus]

On 06/07/2012 11:22 PM, Linda Walsh wrote:
> In reading the messages quoted above, I'm not sure some people
> understand the severity of the bug.

I do not.
And many people don't understand expansions, quoting, completions and
many other...

>
> This isn't a matter of preference... its a real bug.
>
> Ex:
> $ ls $HOME/bin<TAB><RETURN>
> "ls: cannot access $HOME/bin: No such file or directory"

quoting and completion

>
> It's not about expansion or non-expansion during the editing phase--
> that would be a matter of preference, it's that when you hit enter,
> it doesn't expand the variables -- which I can't see being useful for
> anyone.
>
> Note -- this is the same type of problem as Bash not correcting
> the case of path components.

Why would bash do that?

>
> Bash isn't correcting the lines anymore so that final
> expansions match real paths...
>
>
> When I originally heard 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, there is a bug also in bash-completion package,
which need to be fixed.
Many people uses bash-completion, even they don't know it.

RR