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.
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
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/
*** Bug 709907 has been marked as a duplicate of this bug. ***
*** Bug 739472 has been marked as a duplicate of this bug. ***
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 ...
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.
$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?
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
(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.
(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.
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
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
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).
[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
$ 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?
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...
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.
(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.
(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.
For testers: * make sure you are running updated bash * make sure you are not using programmable completion
bash-4.2.29-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Other than getting rid of \$PWD/ in the response to $PWD<tab> the expected and desired expansion of $PWD just doesn't happen. I used "complete -r" and tried both the pushed version for 17 and the testing version for 16, neither returned to expected behavior. I often use a define for some long path section if I am working in multiple directories in addition to the PWD. I really don't want the unexpanded symbols in history where I might rerun a command using a new value. To that extent this is definitely a security issue. I tried this on a few really old machines, the $PWD/<tab> notation has expanded at least since fc10, and doesn't in in 4.2.29-1 by default. I could live with having to set completion options, but this behavior is really undesirable.
(In reply to comment #23) > Other than getting rid of \$PWD/ in the response to $PWD<tab> the expected > and desired expansion of $PWD just doesn't happen. I used "complete -r" and > tried both the pushed version for 17 and the testing version for 16, neither > returned to expected behavior. I often use a define for some long path > section if I am working in multiple directories in addition to the PWD. I > really don't want the unexpanded symbols in history where I might rerun a > command using a new value. To that extent this is definitely a security > issue. > > I tried this on a few really old machines, the $PWD/<tab> notation has > expanded at least since fc10, and doesn't in in 4.2.29-1 by default. I could > live with having to set completion options, but this behavior is really > undesirable. You can use direxpand shell option: $ echo $PWD/ after tab completion $PWD/ is unchanged $ shopt -s direxpand $ echo $PWD/ after tab the line is changed to $ echo /home/rrakus/
bash-4.2.36-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/bash-4.2.36-1.fc16
bash-4.2.37-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/bash-4.2.37-1.fc16
bash-4.2.37-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Roman Rakus from comment #24) > $ shopt -s direxpand > > $ echo $PWD/ > after tab the line is changed to > $ echo /home/rrakus/ It has another regression: $ echo ~/ <tab><tab> and nothing happens, even CTRL-E does not work. After $ shopt -u direxpand $ echo ~/ <tab><tab> Display all 161 possibilities? (y or n)
(In reply to Jan Kratochvil from comment #28) > (In reply to Roman Rakus from comment #24) > > $ shopt -s direxpand > > > > $ echo $PWD/ > > after tab the line is changed to > > $ echo /home/rrakus/ > > It has another regression: > > $ echo ~/ > <tab><tab> > and nothing happens, even CTRL-E does not work. > > After > $ shopt -u direxpand > $ echo ~/ > <tab><tab> > Display all 161 possibilities? (y or n) I can't reproduce it: $ shopt | grep direxpand direxpand on $ echo ~/<tab<tab> Display all 145 possibilities? (y or n) $ complete (means I have no programmable completions) What does ~ expands to? I'm using bash 4.2.39
Sorry but I also do not have it reproducible now (bash-4.2.45-1.fc19.x86_64). I have no idea why it did not work for me above.