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: Backspace echoed incorrectly with TERM=garbage
On 6/19/20 7:53 PM, Bryan Henderson wrote: > I tracked it down to an Ncurses change. > > Bash/readline attempts to move the cursor left by calling Ncurses (libtinfo) > function 'tputs' with ASCII BS (ctl-H) as the argument. The function of > 'tputs' is to write stuff to the terminal with delays added, as required by > early printing terminals. > > In the past, if TERM were set to something undefined, tputs would go ahead and > write the BS to the terminal, but in the libtinfo linked to Bash on my Debian > 10 system, tputs fails (returns failure code without writing anything to the > terminal) if TERM is set to something undefined. (It still works if TERM > isn't defined at all, though). Bash ignores the failure and continues, > writing a space to the terminal, followed by another failing call to 'tputs' > for the final backspace. This is consistent with what I discovered, which is that tputs does not call the character output function passed as the third argument at all. I don't know why the ncurses maintainers changed this in version 6, though I suspect they had some rationale for it at the time. It looks like a departure from historical versions of curses/ncurses. The historical behavior (what readline expects) of tputs is to set the amount of padding required to 0 if the terminal type is unknown, which basically makes it an indirect per-character function call. From what I've seen, it fails only if the string parameter is NULL. -- ``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/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
