in reply to Re: What does ">>" do? (And other stat questions)
in thread What does ">>" do? (And other stat questions)
Hello Rolf
> Sorry, you're asking too many questions at the same time to be easily answered in one thread.
I think I agree with you. When I started typing, I really only wanted to know what ">>" was. But as I was typing it became clear to me that I don't understand more than I initially though (or I understand less than I initially thought).
Apparently I'm lacking some fundamental knowledge which is hampering my understanding of stat on the whole.
> First step, plz try to read the docs and tell us what remains unclear: perldoc perlop
Thanks for this, there's usually a perldoc that I've overlooked
> (BTW: perlop is the second hit for perl binary operator )
Thanks for this. My search for "perl binary" was clearly insufficient. And the first hit 1 sort of explains bitwise operators. I think the examples are doing EXACTLY the same thing (albeit with values for text formatting and not file permissions, but I think the concept is the same). But here's where I'm stumped. How does 128 become 10000000 amd 16 become 00010000? Is that just the integer converted to a binary number? The "or" makes sense in this case. I think if we & 10000000 and 00010000 we would get 0110111, right? How would this apply to octal numbers?
> '&' is not a part of the word but a "binary and" operator. But I agree that the missing space doesn't improve readability.
Ok, cool. So we're doing some binary operation on an integer and an octal "07777"? right? I thought binary operations had to be performed on integers? (And why would binary operations on integers be performed as floating point integers? That's more curiosity and I don't think important to my comprehension of the topic)
I think I kinda get WHAT a bitwise shift is, e.g. "00000100 << 2" would be 00010000
In the context of my program, or any program, what does that signify and when/why would I want to do it?
> Do you know how file-permissions are managed in unix-like systems?
After this thread, and speaking as an experienced Unix/Linux SysAdmin: apparently not...
In a nutshell, the permissions are represented as one digit in a three digit octal number. E.g. 0555 (chmod assumes octal so the 0 is often omitted) would be read and execute permissions for user, group, and other. likewise 0777 is the TRUE mark of the beast as it gives read, write, and execute permissions to everyone (and often "nobody" or "www-data"...)
Ok... so. if 4 is represented in binary as 100, 2 is 010, and 1 is 001, and you "or" 4 and 2 together:
100 | 010 = 110
Which is 6
HOLY CRAP I think it makes sense all of a sudden... And that answers my question about octal numbers, just like regular integers, they're just converted by decimal place? (well... kinda 0111 would be 001001001 right?)
So WTF is the deal with with "&07777"
if we're "and"ing I know that and returns the values that are the same... how does this help me? since 07777 is 111111111111 right? What practical implications does this have?
Literal octal numbers start with a 0 followed by octal digits. see perlnumber
Oh. An octal number IS an integer. Ok, that answers my question about bitwise operators.
> see also oct for a discussion of your code
That's a little bit cleaner. Is there a good way to compare octal numbers? (googling "perl compare octal values" returned your link and some really old links. none of which say you should compare them as strings (with "eq") or as integers. Some experimenting seems to indicate that perl can compare them as numbers, since they are...
perl -e 'print "yes\n" if "0777" == "0777"' perl -e 'print "yes\n" if "0777" == "0776"'
Thanks for your help. Even just your responses gave me a target in my research and responding to you helped my understanding greatly. Thanks so much for your help!
1 http://www.cs.cf.ac.uk/Dave/PERL/node36.html
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^3: What does ">>" do? (And other stat questions)
by LanX (Saint) on Nov 01, 2013 at 02:59 UTC | |
by three18ti (Monk) on Nov 03, 2013 at 00:36 UTC |