{
    "mode": "perldoc",
    "parameter": "want",
    "section": "-q",
    "url": "https://www.chedong.com/phpMan.php/perldoc/want/json",
    "generated": "2026-06-09T21:45:24Z",
    "sections": {
        "Found in /usr/share/perl/5.34/pod/perlfaq4.pod": {
            "content": "Why doesn't & work the way I want it to?\nThe behavior of binary arithmetic operators depends on whether they're\nused on numbers or strings. The operators treat a string as a series of\nbits and work with that (the string \"3\" is the bit pattern 00110011).\nThe operators work with the binary form of a number (the number 3 is\ntreated as the bit pattern 00000011).\n\nSo, saying \"11 & 3\" performs the \"and\" operation on numbers (yielding\n3). Saying \"11\" & \"3\" performs the \"and\" operation on strings (yielding\n\"1\").\n\nMost problems with \"&\" and \"|\" arise because the programmer thinks they\nhave a number but really it's a string or vice versa. To avoid this,\nstringify the arguments explicitly (using \"\" or \"qq()\") or convert them\nto numbers explicitly (using \"0+$arg\"). The rest arise because the\nprogrammer says:\n\nif (\"\\020\\020\" & \"\\101\\101\") {\n# ...\n}\n\nbut a string consisting of two null bytes (the result of \"\"\\020\\020\" &\n\"\\101\\101\"\") is not a false value in Perl. You need:\n\nif ( (\"\\020\\020\" & \"\\101\\101\") !~ /[^\\000]/) {\n# ...\n}\n\nHow can I prevent addition of unwanted keys into a hash?\nSince version 5.8.0, hashes can be *restricted* to a fixed number of\ngiven keys. Methods for creating and dealing with restricted hashes are\nexported by the Hash::Util module.\n",
            "subsections": []
        },
        "Found in /usr/share/perl/5.34/pod/perlfaq5.pod": {
            "content": "I still don't get locking. I just want to increment the number in the file. How can I do this?\nDidn't anyone ever tell you web-page hit counters were useless? They\ndon't count number of hits, they're a waste of time, and they serve only\nto stroke the writer's vanity. It's better to pick a random number;\nthey're more realistic.\n\nAnyway, this is what you can do if you can't help yourself.\n\nuse Fcntl qw(:DEFAULT :flock);\nsysopen my $fh, \"numfile\", ORDWR|OCREAT or die \"can't open numfile: $!\";\nflock $fh, LOCKEX                        or die \"can't flock numfile: $!\";\nmy $num = <$fh> || 0;\nseek $fh, 0, 0                            or die \"can't rewind numfile: $!\";\ntruncate $fh, 0                           or die \"can't truncate numfile: $!\";\n(print $fh $num+1, \"\\n\")                  or die \"can't write numfile: $!\";\nclose $fh                                 or die \"can't close numfile: $!\";\n\nHere's a much better web-page hit counter:\n\n$hits = int( (time() - 850000000) / rand(1000) );\n\nIf the count doesn't impress your friends, then the code might. :-)\n\nAll I want to do is append a small amount of text to the end of a file. Do I still have to use locking?\nIf you are on a system that correctly implements \"flock\" and you use the\nexample appending code from \"perldoc -f flock\" everything will be OK\neven if the OS you are on doesn't implement append mode correctly (if\nsuch a system exists). So if you are happy to restrict yourself to OSs\nthat implement \"flock\" (and that's not really much of a restriction)\nthen that is what you should do.\n\nIf you know you are only going to use a system that does correctly\nimplement appending (i.e. not Win32) then you can omit the \"seek\" from\nthe code in the previous answer.\n\nIf you know you are only writing code to run on an OS and filesystem\nthat does implement append mode correctly (a local filesystem on a\nmodern Unix for example), and you keep the file in block-buffered mode\nand you write less than one buffer-full of output between each manual\nflushing of the buffer then each bufferload is almost guaranteed to be\nwritten to the end of the file in one chunk without getting intermingled\nwith anyone else's output. You can also use the \"syswrite\" function\nwhich is simply a wrapper around your system's write(2) system call.\n\nThere is still a small theoretical chance that a signal will interrupt\nthe system-level \"write()\" operation before completion. There is also a\npossibility that some STDIO implementations may call multiple system\nlevel \"write()\"s even if the buffer was empty to start. There may be\nsome systems where this probability is reduced to zero, and this is not\na concern when using \":perlio\" instead of your system's STDIO.\n",
            "subsections": []
        }
    },
    "flags": [],
    "examples": [],
    "see_also": []
}