Re: pwd and prompt don't update after deleting current working directory
Oops I forgot the reply to all in my reply to @David Hedlund I was on the same tune as you @g...@wooledge.org . == On Fri, Jul 12, 2024 at 12:14 AM David Hedlund wrote: > > > When a directory is deleted while the user is inside it, the terminal > should automatically return to the parent directory. > > Jeez, this looks like pretty dangerous isn't it, imagine a script (or a fast typer for interactive shell) the is doing some bookeeping inside a directory, (i.e removing some files in the $PWD), and $PWD is unlinked by another random process, then your script (or fast typer, who type and read afterwards) would then continue its bookeeping in the parent (of login shell dir?). It make no sense. So when a $PWD is unlinked while working in it, the only things a shell can do is to emit a message like $ rm -rf $PWD $ >xyz bash: xyz: No such file or directory Now you may argue this is not explicit enough, nothing in there tells you that the $PWD was unexpectedly unlinked. You may implement something more explicit like this for interactive shell, for script simply bail out on error. $ PS1='$(ls $PWD>/dev/null 2>&1||echo $PWD was unlinked)\n$ ' $ pwd /home/phi/tmp/yo $ ls asd qwe rty $ rm -rf $PWD /home/phi/tmp/yo was unlinked $ ls /home/phi/tmp/yo was unlinked $ cd .. $ mkdir -p yo/asd ; >yo/qwe >yo/rty ; cd yo $ pwd /home/phi/tmp/yo = Bottom line, this is not a bug, and there is no enhancement request here. Or 'may be' on bash error bash: xyz: No such file or directory the full path could be expanded bash: /home/phi/tmp/yo/xyz: No such file or directory But even that I am not sure.
Re: pwd and prompt don't update after deleting current working directory
On Fri, Jul 12, 2024 at 10:26:54 +0700, Robert Elz wrote: > Is it supposed to continually run "stat($PWD, ...)" forever (after > all the directory might be removed from elsewhere while you're in > the middle of typing a command - what do you expect to happen then?) It's even worse: let's say a new option is added, to have bash stat $PWD before or after every command is executed. If the stat fails, then bash changes directory. Then let's say you write a script, and run it under bash using this new option. If the script's working directory is unlinked, and this new option triggers, then bash will change its working directory. This could happen in between *any* pair of commands. The script won't even know that it happened, and won't be expecting it. Essentially, this would make it impossible to use any relative pathnames safely. A script has to *know* what its working directory is, or it has to use only absolute pathnames. Otherwise, something like this: cd "$mydir" || exit touch "$tmpfile" ... rm -f "$tmpfile" could end up removing a temp file (accessed via a relative pathname) from the wrong directory, because the working directory changed before the rm command was executed.
Re: pwd and prompt don't update after deleting current working directory
Date:Fri, 12 Jul 2024 03:53:01 +0200 From:David Hedlund Message-ID: <820e6ee2-7444-4a01-991a-3530c2591...@gnu.org> | Thanks, Lawrence! I found this discussion helpful and believe it would | be a valuable feature to add. Can I submit this as a feature request? You can try, but don't expect it to succeed. Apart from this not being desirable behaviour at all (the directory bash is in still exists as long as it is being referenced, there's just no longer a path which reaches it from "/") how exactly do you expect bash to discover that the directory it is in has been orphaned like that? Is it supposed to continually run "stat($PWD, ...)" forever (after all the directory might be removed from elsewhere while you're in the middle of typing a command - what do you expect to happen then?) kre
Re: pwd and prompt don't update after deleting current working directory
On Thu, Jul 11, 2024, at 9:53 PM, David Hedlund wrote: > On 2024-07-12 00:54, Lawrence Velázquez wrote: >> (You're free to argue that bash *should* behave this way, but that's >> a feature request, not a bug report. And having bash automatically >> update its working directory based on filesystem changes would open >> up its own can of worms.) >> > Thanks, Lawrence! I found this discussion helpful and believe it would > be a valuable feature to add. Can I submit this as a feature request? You've effectively done so already; there's no separate process to follow. This discussion is the feature request, and the maintainer will read it eventually. I only drew the distinction because the current behavior is intentional, so your argument cannot be "bash has a bug". -- vq
Re: pwd and prompt don't update after deleting current working directory
On Thu, Jul 11, 2024 at 7:32 PM David Hedlund wrote: (...) > I understand. So the feature request should be an option "-b" (for > bounce out of the directory when deleted) for example? > It'd be helpful to know about the use cases for such feature though. My assumptions: - This would only be useful in interactive sessions. Portable scripts would not have access to this feature, and so in these cases the script writer must explicitly consider the case where $PWD is unlinked while the process is running. Or decide that it's not worth handling. - In an interactive session: What are the conditions that lead to a directory being removed without the user's knowledge? - Also, what's wrong with letting a user deal with this by issuing `cd ..`? Surely, this doesn't happen frequently enough that it merits increasing the complexity of Bash to handle it automatically.
Re: pwd and prompt don't update after deleting current working directory
On Thu, Jul 11, 2024 at 7:20 PM David wrote: (...) > Hi, I disagree, and I think if you understand better why this occurs, you > will understand why knowledgable users will disagree, and you will > change your opinion. > I concur. The requested feature changes behavior in a backwards-incompatible way, and thus it is guaranteed to break existing scripts. The semantics of file removal in POSIX systems is well-defined, and users of Bash and other POSIX compliant shells should make an effort to learn about them, instead of changing every system to match their mental model.
Re: pwd and prompt don't update after deleting current working directory
On 2024-07-12 04:19, David wrote: n Thu, 11 Jul 2024 at 22:14, David Hedlund wrote: When a directory is deleted while the user is inside it, the terminal should automatically return to the parent directory. Hi, I disagree, and I think if you understand better why this occurs, you will understand why knowledgable users will disagree, and you will change your opinion. This is a fundamental aspect of how Unix-like operating systems work, and it will not be changed because it is very useful in other situations. It occurs because of the designed behaviour of the 'unlink' system call. You can read about that in 'man 2 unlink'. Expected behaviour When a directory is deleted while the user is inside it, the terminal should automatically return to the parent directory. Actual behaviour The terminal remains in the deleted directory's path, even though the directory no longer exists. Your final phrase there "the directory no longer exists" is incorrect. The directory does still exist. The 'rm' command did not destroy it. Any processes that have already opened it can continue to use it. The terminal is one of those processes. Deleting any file (including your directory, because directories have file-like behaviour in this respect, same as every other directory entry) just removes that file object from its parent directory entries. It does not destroy the file in any way. That means that no new processes can access the file, because now there's no normal way to discover that it exists, because it no longer appears in its parent directory entries. But any process that already has the file open can continue to use it. So your directory does not cease to exist until nothing is using it, and even then it is not destroyed, merely forgotten entirely. Here's more explanation: https://en.wikipedia.org/wiki/Rm_(Unix)#Overview I understand. So the feature request should be an option "-b" (for bounce out of the directory when deleted) for example?
Re: pwd and prompt don't update after deleting current working directory
n Thu, 11 Jul 2024 at 22:14, David Hedlund wrote: > When a directory is deleted while the user is inside it, the terminal > should automatically return to the parent directory. Hi, I disagree, and I think if you understand better why this occurs, you will understand why knowledgable users will disagree, and you will change your opinion. This is a fundamental aspect of how Unix-like operating systems work, and it will not be changed because it is very useful in other situations. It occurs because of the designed behaviour of the 'unlink' system call. You can read about that in 'man 2 unlink'. > Expected behaviour > When a directory is deleted while the user is inside it, the terminal > should automatically return to the parent directory. > Actual behaviour > The terminal remains in the deleted directory's path, even though the > directory no longer exists. Your final phrase there "the directory no longer exists" is incorrect. The directory does still exist. The 'rm' command did not destroy it. Any processes that have already opened it can continue to use it. The terminal is one of those processes. Deleting any file (including your directory, because directories have file-like behaviour in this respect, same as every other directory entry) just removes that file object from its parent directory entries. It does not destroy the file in any way. That means that no new processes can access the file, because now there's no normal way to discover that it exists, because it no longer appears in its parent directory entries. But any process that already has the file open can continue to use it. So your directory does not cease to exist until nothing is using it, and even then it is not destroyed, merely forgotten entirely. Here's more explanation: https://en.wikipedia.org/wiki/Rm_(Unix)#Overview
Re: pwd and prompt don't update after deleting current working directory
On 2024-07-12 00:54, Lawrence Velázquez wrote: On Thu, Jul 11, 2024, at 6:08 PM, David Hedlund wrote: Expected behaviour When a directory is deleted while the user is inside it, the terminal should automatically return to the parent directory. ``` user@domain:~/test$ mkdir ~/test && cd ~/test && touch foo && ls foo user@domain:~/test$ rm -r ~/test user@domain:~/$ ``` Why do you expect this behavior? Other shells and utilities typically do what bash does -- i.e., nothing. (You're free to argue that bash *should* behave this way, but that's a feature request, not a bug report. And having bash automatically update its working directory based on filesystem changes would open up its own can of worms.) Thanks, Lawrence! I found this discussion helpful and believe it would be a valuable feature to add. Can I submit this as a feature request?
Re: Local variable can not unset within shell functions
Date:Thu, 11 Jul 2024 16:01:20 -0400 From:Chet Ramey Message-ID: <2739cbbc-d44e-423e-869e-f2884c148...@case.edu> | The bug in bash-4.2 was that [...] | This would have been clearer to see (and more misleading) if the variable | x also had a value at the global scope. If anything, I'd say that the fix does not go far enough. There is no conceptual difference (in sh) between any type of unset variables, whatever other attributes they might have. All the conceivable variables that could ever exist are essentially just unset, with no assigned attributes (unless the -a option is enabled, in which case all those unset, unknown, variables have the export attribute), until they are perhaps given one - they remain unset until given a value. To the implementation they're different, there's no way for the implementation to remember every possible variable name, with its non-value and no attributes, nor is there any point, such a thing can be created whenever it is required to exist, and then destroyed again later - but that's just an implementation technique, another would be for variables once created to be retained forever, even if unset and with no attributes. But there's no reason to expose any of this to the application, all unset variables should behave identically - whether they have attributes or not (except in how the attribute affects them when a value is assigned). So, I'd say that the current bug is, from the original report here: wer...@suse.de said: | ... for global variables it works as expected. That should be fixed, and "declare -p var_name_never_seen_before" should output either declare -- var_name_never_seen_before or perhaps, if it has no attributes unset -v var_name_never_seen_before If that result is later eval'd, perhaps in a different shell instance, where that name has also never previously been noted, then whether or not the shell creates a variable struct for it, or not, is irrelevant to anything (except implementation convenience) and the behaviour should be identical. That is, other than syntactically incorrect variable names, declare -p should never generate an error. Further, if "localness" is considered an attribute of a variable (which isn't how I would implement it, but assuming it is) then surely declare should have an option to set the local attribute, and declare -p should generate a command which restores that (just as it does for the export attribute, the integer attribute, and I assume, others. kre
Re: pwd and prompt don't update after deleting current working directory
On Thu, Jul 11, 2024, at 6:08 PM, David Hedlund wrote: > Expected behaviour > When a directory is deleted while the user is inside it, the terminal > should automatically return to the parent directory. > > ``` > user@domain:~/test$ mkdir ~/test && cd ~/test && touch foo && ls > foo > user@domain:~/test$ rm -r ~/test > user@domain:~/$ > ``` Why do you expect this behavior? Other shells and utilities typically do what bash does -- i.e., nothing. (You're free to argue that bash *should* behave this way, but that's a feature request, not a bug report. And having bash automatically update its working directory based on filesystem changes would open up its own can of worms.) -- vq
pwd and prompt don't update after deleting current working directory
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall uname output: Linux blues-System-Product-Name 5.15.0-113-generic #123+11.0trisquel30 SMP Wed Jun 26 05:33:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.1 Patch Level: 16 Release Status: release [Originally submitted to https://github.com/mate-desktop/mate-terminal/issues/459. A user replied "I don't think this should concern MATE-Terminal, it's a question of the shell itself IMO." - https://github.com/mate-desktop/mate-terminal/issues/459#issuecomment-276438] When a directory is deleted while the user is inside it, the terminal should automatically return to the parent directory. Expected behaviour When a directory is deleted while the user is inside it, the terminal should automatically return to the parent directory. ``` user@domain:~/test$ mkdir ~/test && cd ~/test && touch foo && ls foo user@domain:~/test$ rm -r ~/test user@domain:~/$ ``` Actual behaviour The terminal remains in the deleted directory's path, even though the directory no longer exists. Steps to reproduce the behaviour Create a new directory and navigate into it: ``` user@domain:~/test$ mkdir ~/test && cd ~/test && touch foo && ls foo ``` Delete the directory while still inside it: ``` user@domain:~/test$ rm -r ~/test ``` MATE general version 1.26.0 Package version 1.26.0 Linux Distribution Trisquel 11
Re: Local variable can not unset within shell functions
On 7/11/24 9:42 AM, Dr. Werner Fink wrote:
Hi,
I've a report that with later bash the following which works in bash-4.2
x () {
local x=y
declare -p x
echo $x
unset x
declare -p x
echo $x
}
with
linux-40cm:~ # x () {
> local x=y
> declare -p x
> echo $x
> unset x
> declare -p x
> echo $x
> }
linux-40cm:~ # x
declare -- x="y"
y
-bash: declare: x: not found
but with bash-5.X the reporter sees (and complains)
sl15sp5:~ # x () {
> local x=y
> declare -p x
> echo $x
> unset x
> declare -p x
> echo $x
> }
sl15sp5:~ # x
declare -- x="y"
y
declare -- x
The variable is unset: it has attributes (local) but has not been assigned
a value.
The idea behind preserving the local attribute is that the variable will
continue to be reported as unset while in the function, but assigning it
a new value will preserve it as a local variable. This is how bash has
behaved since 1995 (bash-2.0).
The bug in bash-4.2 was that it didn't tell you which instance of a
variable the shell would modify if it were subsequently assigned a value.
The local variable still exists, is unset, and would be used by expansions
and assignments, but `declare' would not tell you that.
This would have been clearer to see (and more misleading) if the variable
x also had a value at the global scope.
A discussion that prompted the change starts at
https://lists.gnu.org/archive/html/bug-bash/2013-11/msg0.html
Chet
--
``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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Local variable can not unset within shell functions
On Thu, Jul 11, 2024 at 15:39:41 -0400, Lawrence Velázquez wrote:
> I won't speculate about the issue, but your subject goes too far.
> The variable really is unset here:
>
> % cat /tmp/x.bash
> x() {
> local x=y
> declare -p x
> echo "x is ${x-unset}"
> unset x
> declare -p x
> echo "x is ${x-unset}"
> }
>
> x
> % bash /tmp/x.bash
> declare -- x="y"
> x is y
> declare -- x
> x is unset
It looks like newer versions of bash retain *some* memory of the unset
local variable's name, but not its flags or prior contents.
hobbit:~$ f() { local -i x=0; declare -p x; unset x; declare -p x; }
hobbit:~$ f
declare -i x="0"
declare -- x
Lawrence is spot on with the semantics, though. The unset variable
behaves exactly like a variable that was never set.
hobbit:~$ g() { local -i x=0; unset x; echo "plus:${x+plus} minus:${x-minus}";}
hobbit:~$ g
plus: minus:minus
So the question is why Werner's associate cares enough about the output
of declare -p to call this a bug, rather than a simple change of internal
implementation.
Is there some actual semantic difference in behavior between bash versions
that we need to be concerned about here?
Re: Local variable can not unset within shell functions
On Thu, Jul 11, 2024, at 9:42 AM, Dr. Werner Fink wrote:
> I've a report that with later bash the following which works in bash-4.2
>
> [...]
>
> linux-40cm:~ # x () {
> > local x=y
> > declare -p x
> > echo $x
> > unset x
> > declare -p x
> > echo $x
> > }
> linux-40cm:~ # x
> declare -- x="y"
> y
> -bash: declare: x: not found
>
> but with bash-5.X the reporter sees (and complains)
>
> sl15sp5:~ # x () {
> > local x=y
> > declare -p x
> > echo $x
> > unset x
> > declare -p x
> > echo $x
> > }
> sl15sp5:~ # x
> declare -- x="y"
> y
> declare -- x
>
> ... for global variables it works as expected.
I won't speculate about the issue, but your subject goes too far.
The variable really is unset here:
% cat /tmp/x.bash
x() {
local x=y
declare -p x
echo "x is ${x-unset}"
unset x
declare -p x
echo "x is ${x-unset}"
}
x
% bash /tmp/x.bash
declare -- x="y"
x is y
declare -- x
x is unset
--
vq
Re: Local variable can not unset within shell functions
On Thu, Jul 11, 2024, 16:34 alex xmb sw ratchev wrote:
>
>
> On Thu, Jul 11, 2024, 15:42 Dr. Werner Fink wrote:
>
>> Hi,
>>
>> I've a report that with later bash the following which works in bash-4.2
>>
>> x () {
>> local x=y
>> declare -p x
>> echo $x
>> unset x
>> declare -p x
>> echo $x
>> }
>>
>> with
>>
>> linux-40cm:~ # x () {
>> > local x=y
>> > declare -p x
>> > echo $x
>> > unset x
>> > declare -p x
>> > echo $x
>> > }
>> linux-40cm:~ # x
>> declare -- x="y"
>> y
>> -bash: declare: x: not found
>>
>> but with bash-5.X the reporter sees (and complains)
>>
>> sl15sp5:~ # x () {
>> > local x=y
>> > declare -p x
>> > echo $x
>> > unset x
>> > declare -p x
>> > echo $x
>> > }
>> sl15sp5:~ # x
>> declare -- x="y"
>> y
>> declare -- x
>>
>
> id aay the v5 is more valid as error got replaced by working code (
> var=foo ; sav=$( declare -p var ) ; .. ; eval "$var" ( or maybe another
> noeval version )
>
sorry , eval "$sav" , not $var
greets
>
> ... for global variables it works as expected.
>>
>> Werner
>>
>> --
>> "Having a smoking section in a restaurant is like having
>> a peeing section in a swimming pool." -- Edward Burr
>>
>
Re: Local variable can not unset within shell functions
On Thu, Jul 11, 2024, 15:42 Dr. Werner Fink wrote:
> Hi,
>
> I've a report that with later bash the following which works in bash-4.2
>
> x () {
> local x=y
> declare -p x
> echo $x
> unset x
> declare -p x
> echo $x
> }
>
> with
>
> linux-40cm:~ # x () {
> > local x=y
> > declare -p x
> > echo $x
> > unset x
> > declare -p x
> > echo $x
> > }
> linux-40cm:~ # x
> declare -- x="y"
> y
> -bash: declare: x: not found
>
> but with bash-5.X the reporter sees (and complains)
>
> sl15sp5:~ # x () {
> > local x=y
> > declare -p x
> > echo $x
> > unset x
> > declare -p x
> > echo $x
> > }
> sl15sp5:~ # x
> declare -- x="y"
> y
> declare -- x
>
id aay the v5 is more valid as error got replaced by working code ( var=foo
; sav=$( declare -p var ) ; .. ; eval "$var" ( or maybe another noeval
version )
greets
... for global variables it works as expected.
>
> Werner
>
> --
> "Having a smoking section in a restaurant is like having
> a peeing section in a swimming pool." -- Edward Burr
>
Local variable can not unset within shell functions
Hi,
I've a report that with later bash the following which works in bash-4.2
x () {
local x=y
declare -p x
echo $x
unset x
declare -p x
echo $x
}
with
linux-40cm:~ # x () {
> local x=y
> declare -p x
> echo $x
> unset x
> declare -p x
> echo $x
> }
linux-40cm:~ # x
declare -- x="y"
y
-bash: declare: x: not found
but with bash-5.X the reporter sees (and complains)
sl15sp5:~ # x () {
> local x=y
> declare -p x
> echo $x
> unset x
> declare -p x
> echo $x
> }
sl15sp5:~ # x
declare -- x="y"
y
declare -- x
... for global variables it works as expected.
Werner
--
"Having a smoking section in a restaurant is like having
a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
Re: proposed BASH_SOURCE_PATH
On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey wrote: > and the BASH_SOURCE > absolute pathname discussion has been bananas, so that's not going in any > time soon. Maybe just create BASH_SOURCE_REAL instead to avoid the gripes. https://gist.github.com/konsolebox/d9fb2fadd2b8b13d96d0aa7ebea836d9#file-bash-source-real-array-var-patch This however introduces heavier changes. I can already see people saying maybe keep this optional. I don't like it because you have to store the context directories to be able to consistently generate the values the moment the option is enabled. The lazy method I mentioned earlier as well will probably introduce more code than this for the same reason. It was only nice in theory. -- konsolebox
