martes, 12 de noviembre de 2013

Renaming 'used' directories in Zsh and Bash

I can't understand why, oh why, neither bash nor zsh can apply the same policy to mv that they apply to umount, so that when trying to umount a volume that is in use, it tells you so.

When the directory you're in is renamed (moved),the shell keeps showing the old path you were in without notifying you in any way that this directory you see in the prompt is not that anymore.

 Probably it's an inode thing: When you change the name to a file/dir, you probably just have to change the inode's name. And I'm fine with it. Anyway it'd be a waste of resources to try to communicate to other open terminals/shells that there's been a change in a remote directory in the system.

That, and probably for thousand reasons I don't even know its existence.

So the question would be. Why couldn't we make bash/zsh check for the existence of the cwd when displaying PS1 if in the PS1 itself there's the metachart to show the directory path (%~ in zsh)?

Sorry if it sounds a bit rude, I just had an amazing debugging session for 2 hours because I was debugging the wrong thing. My bad, I know, but.....

So here's the way to reproduce
[ /tmp ] %mkdir test
[ /tmp ] %cd test 
[ /tmp/test ] %ls
[ /tmp/test ] %mkdir foo
[ /tmp/test ] %echo OHAI >foo/bar
[ /tmp/test ] %cd foo 
[ /tmp/test/foo ] %ls
                                     In another terminal
                                     [ ~ ] %cd /tmp/test 
                                     [ /tmp/test ] %ls
                                     [ /tmp/test ] %mv foo bar
                                     [ /tmp/test ] %ls bar 
[ /tmp/test/foo ] % ls
[ /tmp/test/foo ] %pwd

Is there a reason for that?

PS: My real case was something even more tricky as I changed 'reponame' to 'reponame2', and then recreated 'reponame', so I had different shells pointing to 'the same' path, without being actually the same.