+++ This bug was initially created as a clone of Bug #679696 +++

Description of problem:
I was used for a convenient expansion of $PWD but the behavior has changed.
/usr/share/doc/bash-4.2.0/NEWS does not seem to cover this change.

Version-Release number of selected component (if applicable):
bash-4.2.0-2.fc15.x86_64
(comparing to bash-4.1.7-3.fc14.x86_64)

How reproducible:
Always.

Steps to Reproduce:
$ echo $PWD/<tab>

Actual results:
$ echo \$PWD/

Expected results:
$ echo /home/user/

Additional info:
It was very convenient as one could edit the expanded content afterwards.
I am not aware if this change is intended or not.

--- Additional comment from rrakus on 2011-03-01 09:17:43 EST ---

Upstream discussion: http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00274.html

Especially Chet's answer: http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00296.html

--- Additional comment from jan.kratochvil on 2011-03-01 09:52:10 EST ---

Thanks for the link.
I see now it has become known upstream and one can at least workaround it by:

$ echo $PWD<ctrl-alt-e>
->
$ echo /home/user
or
$ echo $PWD/<ctrl-alt-e>
->
$ echo /home/user/

--- Additional comment from rrakus on 2011-06-02 08:13:16 EDT ---

*** Bug 709907 has been marked as a duplicate of this bug. ***

--- Additional comment from rrakus on 2011-06-07 07:06:26 EDT ---

*** Bug 709907 has been marked as a duplicate of this bug. ***

--- Additional comment from rrakus on 2011-09-19 07:15:16 EDT ---

*** Bug 739472 has been marked as a duplicate of this bug. ***

--- Additional comment from fedoration on 2011-09-19 14:54:11 EDT ---

Well that unintended consequence utterly sucks :(

*Several* times a day I use $PWD/../../<TAB> and rely on the old behaviour

I could live with the new behaviour if $HOME/fo<TAB> expanded to $HOME/foo instead of /home/redi/foo but I really want $HOME/.. to expand to /home

To the bash issue tracker ...

--- Additional comment from fedoration on 2011-09-19 15:02:49 EDT ---

As pointed out by Andreas Schwab on the bash list, expanding $PWD/ to \$PWD/ is utterly useless in every way, it doesn't help you return to the same thing in your history, because it's "completed" what you typed into something completely different and incompatible - I don't want that to happen once, let alone be in my history to reuse it !

Using ~+/ instead of $PWD/ doesn't work for the $PWD/../ case, which used to canonicalize the path by removing the .. components.

--- Additional comment from jan.kratochvil on 2011-09-23 11:45:25 EDT ---

$PWD/gdb -nx -ex 'break main' -ex run ./gdb
ok, works.

CTRL-ALT-E

/home/jkratoch/redhat/gdb-clean/gdb/gdb -nx -ex break main -ex run ./gdb
main: No such file or directory.
".../gdb/./gdb" is not a core dump: File format not recognized
No default breakpoint address now.
Starting program:  
No executable file specified.
Use the "file" or "exec-file" command.

= CTRL-E does not work.

Or was there some other resolution upstream?

--- Additional comment from piergiorgio.sartor on 2011-10-06 04:37:56 EDT ---

This is a really funny issue... :-(

It seems they tried to solve the ambiguity between expanding something like $PWD in to its current value or expanding a file/folder called "$PWD".
In other words, if there is a folder called $PWD, I mean really $PWD, including "$", there is no possibility to decide if the user wants the working directory or the folder itself.
So, previously they expanded the value, now they expand the file/folder name...

Said that, it seems to me upstream people lost their minds, since in any non-ambiguous case, when only a variable exists or (exclusively) only a file/folder, the expansion policy should be quite clear.

In the unfortunate case one has such situation where both a variable *and* a file/folder have the same name, there should be a configuration option which will tell the bash to perform one (variable) or the other (file/folder) expansion.

Now, if this seems reasonable, could the redhat maintainer ask upstream to implement such a solution or provide a patch doing so?

Thanks a lot in advance,

bye,

pg

--- Additional comment from rrakus on 2011-10-19 08:38:17 EDT ---

(In reply to comment #8)
> $PWD/gdb -nx -ex 'break main' -ex run ./gdb
> ok, works.
> 
> CTRL-ALT-E
> 
> /home/jkratoch/redhat/gdb-clean/gdb/gdb -nx -ex break main -ex run ./gdb
> main: No such file or directory.
> ".../gdb/./gdb" is not a core dump: File format not recognized
> No default breakpoint address now.
> Starting program:  
> No executable file specified.
> Use the "file" or "exec-file" command.
> 
> = CTRL-E does not work.
> 
> Or was there some other resolution upstream?

Looks like you misunderstood the behaviour of CTRL-ALT-E, from the man page:
       shell-expand-line (M-C-e)
              Expand the line as the shell does.  This performs alias and his‐
              tory expansion as well as all of the shell word expansions.  See
              HISTORY EXPANSION below for a description of history expansion.

--- Additional comment from rrakus on 2011-10-19 08:59:07 EDT ---

(In reply to comment #9)
> This is a really funny issue... :-(
> 
> It seems they tried to solve the ambiguity between expanding something like
> $PWD in to its current value or expanding a file/folder called "$PWD".
> In other words, if there is a folder called $PWD, I mean really $PWD, including
> "$", there is no possibility to decide if the user wants the working directory
> or the folder itself.
> So, previously they expanded the value, now they expand the file/folder name...
> 
> Said that, it seems to me upstream people lost their minds, since in any
> non-ambiguous case, when only a variable exists or (exclusively) only a
> file/folder, the expansion policy should be quite clear.
> 
> In the unfortunate case one has such situation where both a variable *and* a
> file/folder have the same name, there should be a configuration option which
> will tell the bash to perform one (variable) or the other (file/folder)
> expansion.
> 
> Now, if this seems reasonable, could the redhat maintainer ask upstream to
> implement such a solution or provide a patch doing so?
> 
> Thanks a lot in advance,
> 
> bye,
> 
> pg

Yep. This is also discussed upstream:
http://lists.gnu.org/archive/html/bug-bash/2011-09/msg00007.html

Also there is patch attached. Feel free to test it. In some form it will be in next release of bash.
I can ask upstream to release this patch as official bash 4-2 patch.

--- Additional comment from updates on 2012-05-31 08:05:52 EDT ---

bash-4.2.29-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/bash-4.2.29-1.fc17

--- Additional comment from updates on 2012-05-31 08:19:19 EDT ---

bash-4.2.29-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/bash-4.2.29-1.fc16

--- Additional comment from updates on 2012-06-01 12:52:17 EDT ---

Package bash-4.2.29-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing bash-4.2.29-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-8676/bash-4.2.29-1.fc17
then log in and leave karma (feedback).

--- Additional comment from mrunge on 2012-06-07 04:55:13 EDT ---

[mrunge@mrungexp]$ rpm -q bash
bash-4.2.29-1.fc17.x86_64

[mrunge@mrungexp admin]$ echo \$PWD/<TAB>
$PWD/

Doesn't look like expected in #c1

--- Additional comment from rrakus on 2012-06-07 05:21:36 EDT ---

$ echo $BASH_VERSION
4.2.28(1)-release
$ echo $PWD<TAB> -> $ echo $PWD 
$ echo $PWD/<TAB> -> $ echo \$PWD/
$ echo \$PWD/<TAB> -> unchanged

now run updated version:
$ echo $BASH_VERSION
4.2.29(1)-release
$ echo $PWD<TAB> -> $ echo $PWD
$ echo $PWD/<TAB> -> nothing, on double tab list suggestions
$ echo \$PWD/ -> unchanged, double tab does nothing...

What is not expected?

--- Additional comment from mrunge on 2012-06-07 05:36:53 EDT ---

Steps to Reproduce:
$ echo $PWD/<tab>

Actual results:
$ echo \$PWD/

Expected results:
$ echo /home/user/

doing the same as you above:
[mrunge@mrungexp ~]$ echo $BASH_VERSION
4.2.29(1)-release
[mrunge@mrungexp ~]$ echo $PWD <TAB>
/home/mrunge
$ echo $PWD/<TAB> -> expands to echo \$PWD/, double tab lists nothing
$ echo \$PWD/<TAB> -> unchanged, double tab does nothing...

--- Additional comment from rrakus on 2012-06-07 09:57:48 EDT ---

Hmm, strange... maybe some programmable completion?
I have this:
$ complete
complete -o filenames -F __udisks udisks
complete -o bashdefault -o default -o nospace -F _git git
complete -o bashdefault -o default -o nospace -F _gitk gitk

please try to remove all programmable completions by running `complete -r' and try again.

--- Additional comment from opensource on 2012-06-07 10:24:13 EDT ---

(In reply to comment #18)

> please try to remove all programmable completions by running `complete -r'
> and try again.

After running 'complete -r' echo $PWD/<TAB> does not change as expected, without 'complete -r' the problem persists.

--- Additional comment from rrakus on 2012-06-07 10:42:38 EDT ---

(In reply to comment #19)
> (In reply to comment #18)
> 
> > please try to remove all programmable completions by running `complete -r'
> > and try again.
> 
> After running 'complete -r' echo $PWD/<TAB> does not change as expected,
> without 'complete -r' the problem persists.

So the problem is in some of programmable completion.