> They are not themselves tests, and (as you'd previously asked about in a comment) no compliment is taken in the [ -n -n ] case, simply because the syntax for [ insists that a single argument between [ and ] or after -n is a string operand.
I personally don't understand that sentence - I don't know what is meant by complement. I understand (I think) that -n is a string which is longer than 0 bytes , so [ -n -n ] is true, just like [ -n ] is true (but in the first one, the first -n is a test, whereas in the second one, -n is just the operand (the string)
I might have thought the OP was thinking that when it appeared before another -n, it behaved like !or something -- but if I thought that, then I should have pointed out that -n never does that. It turns out, I think, that when the OP talked about complements in comments, they were referring to -z, which they characterized (reasonably) as the test complementary to -n.
@EliahKagan oh yeah, I read "complementary test" in the question, so I should have realised what you meant
@EliahKagan that's very clear. If it says everything the previous version was saying, I am relieved, because nothing astonishing was revealed in the new version :)
Perhaps it's unreasonable to consider the present working directory to "exist" in that situation, considering that it has been deleted.
Unlike a file whose hard links have all been removed after a process opens it, one cannot change the contents of a directory that has been changed to with cd but then removed, since this would create orphaned entries that would disappear afterwards and would have to be recovered by fsck (or any of a number of vastly harder and less reasonable methods).
@EliahKagan wait, you deleted a directory you're currently in? you know that the node in /proc/ will still exist as long you're inside that deleted directory, so my guess is that pwd for this reason still gives you an output
same happens if you lets say update VLC while you have VLC running, the actual running binary is existent in a node in proc but the file on the drive has changed
Yes, an inode whose link count has dropped to zero is not deleted until nothing has it open anymore. I don't think the commonly given explanation in terms of /proc is accurate, though. Other Unix-like operating systems that don't have a /proc filesystem also behave this way. Furthermore, the entries in /proc are not actually hard links to the open files' inodes, and they do not affect the link count displayed by the stat system call and viewable by running ls -l or stat.