Let's have a look at the followings:

radu@Radu:~$ mkdir test
radu@Radu:~$ cd test
radu@Radu:~/test$ rmdir ~/test
radu@Radu:~/test$ man ls
man: can't change directory to '': No such file or directory

Normally, I would say that the last line from the previous output from my terminal is an error. But how can I understand it? And why does this appear only in the case of man command (as far as I know; even pwd or ls does not have any problem)?

Furthermore, let's see again:

radu@Radu:~/test$ man ls
man: can't change directory to '': No such file or directory
radu@Radu:~/test$ echo $?

What? It was a success (see the output of man man |& grep -A 1 '^EXIT STATUS$')?

Another version of man

When attempted with another version of man the same thing works.

$ mkdir mantst
$ cd mantst/
$ man ls            <--- works
$ rmdir ../mantst/
$ man ls            <--- works
$ man --version
man 2.6.3
  • Your computer is attacked by aliens :D The same commands that you had mentioned perfectly fine for me.
    – Ramesh
    Apr 18, 2014 at 18:24
  • This might also help. That said this is a FAQ of sorts.
    – devnull
    Apr 18, 2014 at 18:25
  • @devnull I did not asked this an I can't find an answer there... Apr 18, 2014 at 18:33
  • 1
    @devnull why is this a dupe? The OP here is asking about a very specific case that's not addressed in the dupe. Their man seems to behave differently.
    – terdon
    Apr 19, 2014 at 11:55
  • 1
    Try running both versions with strace.
    – goldilocks
    Apr 19, 2014 at 15:22

1 Answer 1


The difference between man and other commands like ls is that latter ones (those not complaining about non-existent directory) don't try to explicitly change there but already stay there. Man also does, but it additionally tries to explicitly change there, too.

UNIX directories (as files) aren't deleted immediately when you call unlink(2) or rmdir(2) on them, but just their directory entry in the parent directory is removed. The directory/file stays as long as there are processes referencing them. As soon as the last reference is gone, the kernel effectively removes the blocks belonging to the files/directories.

For this cause there is no error when you call ls in a directory not existing anymore, since your shell is still there (it references the directory as its current directory) and ls started from there just inherits this property. But since man explicitly tries to chdir(2) there, thus to a directory entry that doesn't exist anymore, it bails out.

  • Thank you for your clarification. But what can you say about th exit status which is 0 (success) in this case? Apr 18, 2014 at 19:09
  • That's simply weird. ;) Could you tell me which version of man you're using? Apr 18, 2014 at 19:43
  • man Apr 18, 2014 at 19:47
  • Hm, unclear. tl;dr… The source code is a bit more complicated than I thought, so I'll have to owe you this exact answer. :( Apr 18, 2014 at 19:50
  • Damn, then my first thought was right after all (I guess). Do you something fancy™ with your prompt or similar? Is pre_cmd a defined function? Some shell magic happening between program exit and printing of the prompt would clearly explain the 0 exit status. Apr 18, 2014 at 20:35

You must log in to answer this question.

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