Re^3: What does ">>" do? (And other stat questions)

[Laurent_R]

From your other answers, I think I can help you further by showing the same numbers as above in binary form:

  DB<5> printf "%04b", $mode ;
1000000111101101
  DB<6> printf "%04b",  07777;
111111111111
  DB<7>

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:

  1000000111101101 &
  0000111111111111
  ================
= 0000000111101101

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:

  DB<8> $c = $mode & 07777;

  DB<9> printf "%04b", $c;
111101101
  DB<10>

If I now print that same $c number in its octal representation:

  DB<10> printf "%04o", $c;
0755
  DB<11>

Is it clearer in your mind now?

[three18ti]

Awesome! Thanks so much for the explanation.

I think I understand everything except for why we're essentially throwing away the first four bits. Why are they there to begin with? And why don't we need them?

Thanks again, this is awesome

[Laurent_R]

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:

$ ls -l /etc/passwd
-rw-r--r-- 1 Laurent root 841  9 mai   23:24 /etc/passwd

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

[three18ti]

Ah Ha!

So cool! Thanks for the explanation

So following that logic, could we then mask off the first four bits with 077777?

but that would only be 15 bits, not 16, so probably not.

(Side note, I thought there were 8 bits to a byte?)