phpman > perldoc > want(2)

Found in /usr/share/perl/5.34/pod/perlfaq4.pod
  Why doesn't & work the way I want it to?
    The behavior of binary arithmetic operators depends on whether they're
    used on numbers or strings. The operators treat a string as a series of
    bits and work with that (the string "3" is the bit pattern 00110011).
    The operators work with the binary form of a number (the number 3 is
    treated as the bit pattern 00000011).

    So, saying "11 & 3" performs the "and" operation on numbers (yielding
    3). Saying "11" & "3" performs the "and" operation on strings (yielding
    "1").

    Most problems with "&" and "|" arise because the programmer thinks they
    have a number but really it's a string or vice versa. To avoid this,
    stringify the arguments explicitly (using "" or "qq()") or convert them
    to numbers explicitly (using "0+$arg"). The rest arise because the
    programmer says:

        if ("\020\020" & "\101\101") {
            # ...
        }

    but a string consisting of two null bytes (the result of ""\020\020" &
    "\101\101"") is not a false value in Perl. You need:

        if ( ("\020\020" & "\101\101") !~ /[^\000]/) {
            # ...
        }

  How can I prevent addition of unwanted keys into a hash?
    Since version 5.8.0, hashes can be *restricted* to a fixed number of
    given keys. Methods for creating and dealing with restricted hashes are
    exported by the Hash::Util module.

Found in /usr/share/perl/5.34/pod/perlfaq5.pod
  I still don't get locking. I just want to increment the number in the file. How can I do this?
    Didn't anyone ever tell you web-page hit counters were useless? They
    don't count number of hits, they're a waste of time, and they serve only
    to stroke the writer's vanity. It's better to pick a random number;
    they're more realistic.

    Anyway, this is what you can do if you can't help yourself.

        use Fcntl qw(:DEFAULT :flock);
        sysopen my $fh, "numfile", O_RDWR|O_CREAT or die "can't open numfile: $!";
        flock $fh, LOCK_EX                        or die "can't flock numfile: $!";
        my $num = <$fh> || 0;
        seek $fh, 0, 0                            or die "can't rewind numfile: $!";
        truncate $fh, 0                           or die "can't truncate numfile: $!";
        (print $fh $num+1, "\n")                  or die "can't write numfile: $!";
        close $fh                                 or die "can't close numfile: $!";

    Here's a much better web-page hit counter:

        $hits = int( (time() - 850_000_000) / rand(1_000) );

    If the count doesn't impress your friends, then the code might. :-)

  All I want to do is append a small amount of text to the end of a file. Do I still have to use locking?
    If you are on a system that correctly implements "flock" and you use the
    example appending code from "perldoc -f flock" everything will be OK
    even if the OS you are on doesn't implement append mode correctly (if
    such a system exists). So if you are happy to restrict yourself to OSs
    that implement "flock" (and that's not really much of a restriction)
    then that is what you should do.

    If you know you are only going to use a system that does correctly
    implement appending (i.e. not Win32) then you can omit the "seek" from
    the code in the previous answer.

    If you know you are only writing code to run on an OS and filesystem
    that does implement append mode correctly (a local filesystem on a
    modern Unix for example), and you keep the file in block-buffered mode
    and you write less than one buffer-full of output between each manual
    flushing of the buffer then each bufferload is almost guaranteed to be
    written to the end of the file in one chunk without getting intermingled
    with anyone else's output. You can also use the "syswrite" function
    which is simply a wrapper around your system's write(2) system call.

    There is still a small theoretical chance that a signal will interrupt
    the system-level "write()" operation before completion. There is also a
    possibility that some STDIO implementations may call multiple system
    level "write()"s even if the buffer was empty to start. There may be
    some systems where this probability is reduced to zero, and this is not
    a concern when using ":perlio" instead of your system's STDIO.