Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: =?ISO-8859-1?Q?=C1ngel?= Newsgroups: gnu.bash.bug Subject: Re: Bug on bash shell - $PWD (and consequentely prompt) not updated while renaming current folder. Date: Sun, 21 Jun 2020 01:32:59 +0200 Lines: 84 Approved: bug-bash@gnu.org Message-ID: References: <051e2fbabf3a9912e5d4248efba0f02b@goncalo.pt> <6BF29BAB-6F57-4D88-85BC-56E1AA14F29F@larryv.me> <4c262650-3c37-923f-53f1-358df8c0f9a1@case.edu> <1592695979.4387.27.camel@16bits.net> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1592695992 6891 209.51.188.17 (20 Jun 2020 23:33:12 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org In-Reply-To: <4c262650-3c37-923f-53f1-358df8c0f9a1@case.edu> Received-SPF: pass client-ip=199.195.249.9; envelope-from=angel@16bits.net; helo=mailer.hiddenmail.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/20 19:33:07 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <1592695979.4387.27.camel@16bits.net> X-Mailman-Original-References: <051e2fbabf3a9912e5d4248efba0f02b@goncalo.pt> <6BF29BAB-6F57-4D88-85BC-56E1AA14F29F@larryv.me> <4c262650-3c37-923f-53f1-358df8c0f9a1@case.edu> Xref: csiph.com gnu.bash.bug:16421 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 >=20 > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html#tag_20= _14 >=20 > That converts it to /tmp/old ("." -> "/tmp/old/." -> "/tmp/old") >=20 > 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=3D'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=3D'\w\$ ' ~$ PROMPT_COMMAND=3D'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 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 differe= nt 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 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. >=20 > 7. If the -P option is in effect, proceed to step 10. If curpath does > not begin with a character, set curpath to the string formed > by the concatenation of the value of PWD, a character if the > value of PWD did not end with a character, and curpath. > 10. The cd utility shall then perform actions equivalent to the > chdir() function called with curpath as the path argument. >=20 (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