3

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 $?
0

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 '14 at 18:24
  • This might also help. That said this is a FAQ of sorts. – devnull Apr 18 '14 at 18:25
  • @devnull I did not asked this an I can't find an answer there... – Radu Rădeanu Apr 18 '14 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 '14 at 11:55
  • 1
    Try running both versions with strace. – goldilocks Apr 19 '14 at 15:22
3

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? – Radu Rădeanu Apr 18 '14 at 19:09
  • That's simply weird. ;) Could you tell me which version of man you're using? – Andreas Wiese Apr 18 '14 at 19:43
  • man 2.6.7.1... – Radu Rădeanu Apr 18 '14 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. :( – Andreas Wiese Apr 18 '14 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. – Andreas Wiese Apr 18 '14 at 20:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.