I think you're trying to show me what happens when you binary "&" 33261 and 07777? maybe that doesn't make any sense because the 07777 isn't present in DB<4> but is in DB<5>. I read in a link above that "&" has lower precedence, so that would bean that "printf "%04o", $mode" is evaluated first? But that doesn't make any sense since printf would do the printing... Ok, I thought I was starting to understand... But I don't think I do.

The $mode value is 33261. I wanted to show what happens when you print it with the octal formatting string (prints 100755) and when you do it after having modified it with the binary and (&). And & has a higher precedence than the comma. As you can see below, adding parens to guarantee the right precedence does not modify the output::

So, 33261 is 1000000111101101 in binary representation, and 07777 is 111111111111 (or the equivalent 0000111111111111) in binary representation. If we now do manually a bitwise and (&) between these two numbers, we do this:

We get a 1 in the result only at places where we have a 1 in both numbers above. This is in effect applying a mask to cancel out the four binary digits on the left in the original number. The same operation under the debugger:

The file mode given by stat[2] consists of two distinct pieces of information: the file type and the file permissions. If you want to see only the permissions, you have to mask off the file type portion of the mode. This is what the bitwise and (&) with 07777 does, as shown in my previous post.

The file type corresponds to the first character displayed on a ls -l command under the Unix shell prompt:

The initial dash (-) displayed above says it is a regular file, a d would indicate a directory, a l a symbolic link, an s a socket, etc. This information is the file type displayed in the first half byte (four bits) of the file mode reported by stat[2].