Re: pwd and prompt don't update after deleting current working directory
On 2024-07-16 15:31, Lawrence Velázquez wrote: On Tue, Jul 16, 2024, at 3:47 AM, David Hedlund wrote: Do you think that it would be appropriate to submit this feature request to the developers of the rm command instead. How would this help? The rm utility cannot change the working directory of the shell that invokes it, or of any other process. Even if it could, that wouldn't help you if a different utility/application did the unlinking. (Never mind that there are no canonical "developers of the rm command". GNU is not the only implementation in the world.) I appreciate your input. To be honest, I'm currently juggling multiple tasks and don't have the necessary bandwidth to fully consider this particular issue at the moment. Let's table this discussion for now. For comparision, caja (file manager in MATE) is stepping back as many directories as needed when it is located in a directory that is deleted in bash or caja. Behavior that is appropriate for GUI applications is not necessarily appropriate for CLI utilities, and vice versa. The comparison is inapt.
Re: pwd and prompt don't update after deleting current working directory
On Tue, Jul 16, 2024, at 3:47 AM, David Hedlund wrote: > Do you think that it would be appropriate to submit this feature request > to the developers of the rm command instead. How would this help? The rm utility cannot change the working directory of the shell that invokes it, or of any other process. Even if it could, that wouldn't help you if a different utility/application did the unlinking. (Never mind that there are no canonical "developers of the rm command". GNU is not the only implementation in the world.) > For comparision, caja (file manager in MATE) is stepping back as many > directories as needed when it is located in a directory that is deleted > in bash or caja. Behavior that is appropriate for GUI applications is not necessarily appropriate for CLI utilities, and vice versa. The comparison is inapt. -- vq
Re: pwd and prompt don't update after deleting current working directory
On 7/16/24 3:47 AM, David Hedlund wrote: On 2024-07-12 15:10, Chet Ramey wrote: On 7/11/24 9:53 PM, David Hedlund wrote: 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? I'm not going to add this. It's not generally useful for interactive shells, and dangerous for non-interactive shells. If this is a recurring problem for you, I suggest you write a shell function to implement the behavior you want and run it from PROMPT_COMMAND. That behavior could be as simple as pwd -P >/dev/null 2>&1 || cd .. Do you think that it would be appropriate to submit this feature request to the developers of the rm command instead. You can try, but I would not expect them to implement it. -- ``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: pwd and prompt don't update after deleting current working directory
On 2024-07-12 15:10, Chet Ramey wrote: On 7/11/24 9:53 PM, David Hedlund wrote: 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? I'm not going to add this. It's not generally useful for interactive shells, and dangerous for non-interactive shells. If this is a recurring problem for you, I suggest you write a shell function to implement the behavior you want and run it from PROMPT_COMMAND. That behavior could be as simple as pwd -P >/dev/null 2>&1 || cd .. Do you think that it would be appropriate to submit this feature request to the developers of the rm command instead. For comparision, caja (file manager in MATE) is stepping back as many directories as needed when it is located in a directory that is deleted in bash or caja.
Re: pwd and prompt don't update after deleting current working directory
On 7/11/24 9:53 PM, David Hedlund wrote: 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? I'm not going to add this. It's not generally useful for interactive shells, and dangerous for non-interactive shells. If this is a recurring problem for you, I suggest you write a shell function to implement the behavior you want and run it from PROMPT_COMMAND. That behavior could be as simple as pwd -P >/dev/null 2>&1 || cd .. -- ``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: 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: 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
