Re: Bug on bash shell - $PWD (and consequentely prompt) not updated while renaming current folder.

[Ángel]

On 2020-06-20 at 14:02 -0400, Chet Ramey wrote:
> It's a way to make sure PWD is correct after a `cd'. Without options, `cd'
> canonicalizes its pathname argument in the way POSIX describes in
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html#tag_20_14
> 
> That converts it to /tmp/old ("." -> "/tmp/old/." -> "/tmp/old")
> 
> Since chdir to "/tmp/old" fails, bash falls back to chdir to ".", which
> succeeds, and then recanonicalizes PWD to the true directory pathname, as
> would be returned by `pwd -P'.

Note that, as this explains, PROMPT_COMMAND='cd .' may change your
current directory behind you. I would consider dangerous to have a
command with such side-effects on PROMPT_COMMAND.

Suppose we had different versions of a program (e.g. bash) compiled, and
a symlink bash-latest pointing to the last one

~$ PS1='\w\$ '
~$ PROMPT_COMMAND='cd .'
~$ readlink bash-latest
bash-5.0
~$ cd bash-latest
~/bash-latest$ ./bash --version
GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 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.
~/bash-latest$ ln -snf bash-5.1-alpha ~/bash-latest  # Perhaps by a different 
process
~/bash-latest$ ./bash --version
GNU bash, version 5.1.0(1)-alpha (x86_64-pc-linux-gnu)
Copyright (C) 2020 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.


The hidden command "cd ." changed us into a completely different
directory. Perhaps unexpected for the user (why did the bash version
changed completely in the middle of a test run??).

Reading the above POSIX link, I would expect cd -P . not to have such
side effect.

I read the instructions:

> 6. Set curpath to the directory operand.
> 
> 7. If the -P option is in effect, proceed to step 10. If curpath does
> not begin with a <slash> character, set curpath to the string formed
> by the concatenation of the value of PWD, a <slash> character if the
> value of PWD did not end with a <slash> character, and curpath.

> 10. The cd utility shall then perform actions equivalent to the
> chdir() function called with curpath as the path argument.
> 
(trimmed for clarity)

And would expect "cd -P ." to perform the equivalent of chdir("."),
which should always leave you on the same folder you are in.


However, it appears that it performs the concatenation even when -P is
in effect.
If this was indeed the intention of the Austin group, I think the phrase
"If the -P option is in effect, proceed to step 10." should be the last
one of step 7, not the first. Otherwise, when confronted with "proceed
to step 10", I understand that as an instruction to jump there
*immediately*, not "perform the rest of things on the next phrase, and
afterwards goto 10".


Best regards