1

If I move a directory to the trash that I'm already cd'd into that directory, pwd will report no change in location. I will still be able to do everything in bash normally as if there was no change in the directory, even though Finder says it doesn't exist.

pwd should always be accurate. This does not appear to be the case.

For example, I'm cd'd to this path: /Users/me/Desktop/goingToTrash/subdir

If I move to trash /Users/me/Desktop/goingToTrash, pwd will report that I'm in /Users/me/Desktop/goingToTrash/subdir, even though the finder says it doesn't exist. So if I recreate the deleted directory, bash will be working from the old directory (I'm assuming in the trash, haven't verified yet) instead of the new one I just created, and pwd will provide no clue this happened.

Much worse, if I "move to trash" a directory and I'm cd'd to one of it's subdirectories, then recreate the directory structure, from a sub directory I can cd ../subdir, I'm magically back into the "new" directory, even though the parent was "moved to trash" instead of remaining in the directory structure that was moved to trash.

Improve this question
2
  • Have you tried reloading the bash env? . ~/.bash_profile
    – CJ Dana
    Commented Sep 28, 2016 at 21:46
  • @CJDana The answer below seems to work. I don't want to be concerned about bash's state for any (or in this case every) command. It should always just be "up to date".
    – Zamicol
    Commented Sep 28, 2016 at 21:58

2 Answers 2

Reset to default
3

YMMV when there is an inaction between the shell and the Finder.app. It is best to use-

/bin/pwd

instead of the builtin pwd.

You can add this line to your ~/.bashrc and reset bash to "fix" this problem.

alias pwd="/bin/pwd"

An alternative to /bin/pwd (with or without the alias) is pwd -P. The -P option to the builtin pwd is explained in the output of help pwd.

Improve this answer
2
  • 2
    "The current working directory will only change when done through the shell." is wrong: you can move a folder to the trash in the shell and the built-in pwd won't update (e.g. mv ../../test ~/.Trash/ and your current working directory is /Users/user/test/subdir/)
    – klanomath
    Commented Sep 28, 2016 at 17:32
  • 1
    @Klanomath Correct- will edit post.
    – fd0
    Commented Sep 28, 2016 at 17:46
3

This behavior actually has nothing to do with the .Trash directory. You can get into a similar situation by moving your current working directory to any other location. The pwd command and echo $PWD will both be inaccurate.

What I have found is that starting a new bash process will correctly identify the new location of your current working directory. Therefore a workaround would be to simply "refresh" your current bash process with a new one with the command exec bash.

Improve this answer
3
  • Is there a way to get the terminal prompt to be accurate as well? For example, I'm using export PS1='\u@\H:\w$' to set my prompt. \w is for the current working directory which is still inaccurate.
    – Zamicol
    Commented Sep 28, 2016 at 17:37
  • 2
    cd . seems to force a refresh as well, without the potential problems that replacing the shell has.
    – Gordon Davisson
    Commented Sep 28, 2016 at 17:54
  • 1
    I found that cd . will take you to the wrong directory if a new one exists where you used to be, whereas exec bash always takes you to the original directory.
    – Ben Ganis
    Commented Sep 28, 2016 at 18:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .