> 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.

(from this post)

shouldn't that be a complement rather than a compliment?

I wonder if that sentence of mine is unclear and I should change it further, though.

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.

Is this better?

@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 :)

Speaking of possible astonishment... what are the file time tests of [ supposed to do when a file doesn't exist?

hmm :)

$ [ / -nt /sbin/nonexistent ]
$ echo $?
0

apparently a file that exists is newer than one that does not

$ [ / -ot /sbin/nonexistent ]
$ echo $?
1

Where "exists" is in the sense that name lookup succeeds?

$ mkdir dir1
$ cd dir1
$ rmdir ../dir1
$ [ / -nt . ]
$ echo $?
1
$ ls -d "$(pwd)"
ls: cannot access '/home/ek/dir1': No such file or directory
$ [ / -nt /home/ek/dir1 ]
$ echo $?
0

It makes sense. There is no directory /home/ek/dir1 anymore. Even though it is the name of the present working directory, which does exist.

haha!

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).

it exists like a dream

@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.

eliah can you approve that edit i linked in the raiders chat?