Re: Bug on bash shell - $PWD (and consequentely prompt) not updated while renaming current folder.
On 6/20/20 7:32 PM, Ángel wrote:
> 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 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.
>>
> (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.
It does. The folder is the same, though its name might have changed if
the rename happens out from underneath the shell.
> However, it appears that it performs the concatenation even when -P is
> in effect.
How do you conclude this?
What it does do is part of step 10, which you trimmed.
"If the -P option is in effect, the PWD environment variable shall be set
to the string that would be output by pwd -P."
In the examples we've been using so far, what happens is that the
chdir(".") occurs, $PWD is discarded since it wasn't what `pwd -P' would
have output, the current working directory gets rebuilt using the
equivalent of getcwd(), and PWD is set to that.
Even if you don't rename the directory, $PWD can change in the presence of
symlinks, since `pwd -P' produces a physical path that doesn't contain any
symlinks.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bug on bash shell - $PWD (and consequentely prompt) not updated while renaming current folder.
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
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
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 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.
>
(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
Re: Bug on bash shell - $PWD (and consequentely prompt) not updated while renaming current folder.
On 6/20/20 1:28 PM, Lawrence Velázquez wrote:
> Here's something fun though:
>
> $ PROMPT_COMMAND='cd .'
> $ readlink /tmp
> private/tmp
> $ mkdir /tmp/old
> $ cd /tmp/old
> $ echo "$PWD"
> /tmp/old
> $ mv /tmp/old /tmp/new
> $ echo "$PWD"
> /private/tmp/new
>
> Not wrong, but maybe unexpected to some.
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'.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bug on bash shell - $PWD (and consequentely prompt) not updated while renaming current folder.
On 6/19/20 8:51 PM, corr...@goncalo.pt wrote: > > When we rename the current working directory, $PWD doesn't get updated > as it would as it would if we just did a simple "cd directory". Of course not. There is no mechanism to inform the shell that the file system has changed from underneath it. The shell knows when it changes its own working directory, and can adjust $PWD accordingly. In fact, that is the only thing that changes $PWD. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bug on bash shell - $PWD (and consequentely prompt) not updated while renaming current folder.
> On Jun 20, 2020, at 11:26 AM, Ilkka Virta wrote: > >> On 20.6. 3.51, corr...@goncalo.pt wrote: >> >> When we rename the current working directory, $PWD doesn't get updated >> as it would as it would if we just did a simple "cd directory". Fix: >> Probably: Trigger the current working directory refresh event, like it >> is already done with the cd command. Because we can be renaming our own >> current working directory, so a simple trigger is needed when mv is >> executed and renaming the current working directory. At the same time, > > The directory can get renamed by some completely unrelated background > process, without any action from the shell, so you'd need to recheck > it every time the prompt is printed, not just when a particular > command, or any command, is launched. (The name of the directory > could even change while the shell is waiting for a command line to > be input.) > > Running cd . should reset PWD to show the new name, and if you > need that often, I suppose you could run it from PROMPT_COMMAND: > > /tmp$ PROMPT_COMMAND='cd .' > /tmp$ mkdir old > /tmp$ cd old > /tmp/old$ mv /tmp/old /tmp/new > /tmp/new$ echo $PWD > /tmp/new Here's something fun though: $ PROMPT_COMMAND='cd .' $ readlink /tmp private/tmp $ mkdir /tmp/old $ cd /tmp/old $ echo "$PWD" /tmp/old $ mv /tmp/old /tmp/new $ echo "$PWD" /private/tmp/new Not wrong, but maybe unexpected to some. vq
Re: Bug on bash shell - $PWD (and consequentely prompt) not updated while renaming current folder.
On 20.6. 3.51, corr...@goncalo.pt wrote: When we rename the current working directory, $PWD doesn't get updated as it would as it would if we just did a simple "cd directory". Fix: Probably: Trigger the current working directory refresh event, like it is already done with the cd command. Because we can be renaming our own current working directory, so a simple trigger is needed when mv is executed and renaming the current working directory. At the same time, The directory can get renamed by some completely unrelated background process, without any action from the shell, so you'd need to recheck it every time the prompt is printed, not just when a particular command, or any command, is launched. (The name of the directory could even change while the shell is waiting for a command line to be input.) Running cd . should reset PWD to show the new name, and if you need that often, I suppose you could run it from PROMPT_COMMAND: /tmp$ PROMPT_COMMAND='cd .' /tmp$ mkdir old /tmp$ cd old /tmp/old$ mv /tmp/old /tmp/new /tmp/new$ echo $PWD /tmp/new -- Ilkka Virta / itvi...@iki.fi
Re: Bug on bash shell - $PWD (and consequentely prompt) not updated while renaming current folder.
Hi, > On Jun 19, 2020, at 8:51 PM, corr...@goncalo.pt wrote: > > Bash Version: 5.0 > Patch Level: 11 > Release Status: release > Description: > When we rename the current working directory, $PWD doesn't get updated > as it would as it would if we just did a simple "cd directory". Because > of that, the prompt will continue also to show the old current > directory's name, and not the new name the folder has. But the problem > comes from the current working directory's variable itself (proven by > "echo $PWD") and not by the prompt itself. So it's a lot worse than a > simple prompt update but, it has to do with with environment variables > themselves. As environment variables are session-specific, I submitted > this to you and not to the kernel bug tracking. Please tell me if I > should inform other bug tracking also. Thanks. I'd be hard-pressed to call this a bug, considering that bash is hardly the only shell that behaves this way. % cat /tmp/test rm -fR /tmp/old /tmp/new mkdir /tmp/old cd /tmp/old printf 'pre-mv: %s\n' "$PWD" mv /tmp/old /tmp/new printf 'post-mv: %s\n' "$PWD" % bash --version | head -n 1 GNU bash, version 5.0.17(1)-release (x86_64-apple-darwin18.7.0) % bash /tmp/test pre-mv: /tmp/old post-mv: /tmp/old % zsh --version zsh 5.8 (x86_64-apple-darwin18.7.0) % zsh /tmp/test pre-mv: /tmp/old post-mv: /tmp/old % ksh --version version sh (AT&T Research) 93u+ 2012-08-01 % ksh /tmp/test pre-mv: /tmp/old post-mv: /tmp/old % port -q installed dash dash @0.5.10.2_0 (active) % dash /tmp/test pre-mv: /tmp/old post-mv: /tmp/old % yash --version | head -n 1 Yet another shell, version 2.48 % yash /tmp/test pre-mv: /tmp/old post-mv: /tmp/old -- vq
Bug on bash shell - $PWD (and consequentely prompt) not updated while renaming current folder.
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wno-parentheses -Wno-format-security uname output: Linux localhost.localdomain 5.5.10-200.fc31.x86_64 #1 SMP Wed Mar 18 14:21:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 5.0 Patch Level: 11 Release Status: release Description: When we rename the current working directory, $PWD doesn't get updated as it would as it would if we just did a simple "cd directory". Because of that, the prompt will continue also to show the old current directory's name, and not the new name the folder has. But the problem comes from the current working directory's variable itself (proven by "echo $PWD") and not by the prompt itself. So it's a lot worse than a simple prompt update but, it has to do with with environment variables themselves. As environment variables are session-specific, I submitted this to you and not to the kernel bug tracking. Please tell me if I should inform other bug tracking also. Thanks. Repeat-By: mkdir oldfolder cd oldfolder #Prompt shows oldfolder... mv ../oldfolder ../newfolder #Prompt continues to show oldfolder and not oldfolder... ls -la ls -la .. | grep folder #We confirmed the folder is newfolder and oldfolder doesn't exist anymore... echo $PWD #We confirm that the $PWD keeps the old name and not the new one, thus, not letting prompt being updated... cd .. cd newfolder #Only now the prompt has the new folder name... Fix: Probably: Trigger the current working directory refresh event, like it is already done with the cd command. Because we can be renaming our own current working directory, so a simple trigger is needed when mv is executed and renaming the current working directory. At the same time, if different shells have the same current working directory, probably sending a signal to trigger environment variables on other shells is not practical, maybe each shell should take care of that trigger, to update those variables when noticing the current working directory's name would change, this way each shell would take care of the problem if its own current working directory's name would change. ~ ~
