{
    "content": [
        {
            "type": "text",
            "text": "# make (perldoc)\n\n## Sections\n\n- **Found in /usr/share/perl/5.34/pod/perlfaq2.pod**\n- **Found in /usr/share/perl/5.34/pod/perlfaq3.pod**\n- **Found in /usr/share/perl/5.34/pod/perlfaq4.pod**\n- **Found in /usr/share/perl/5.34/pod/perlfaq5.pod**\n- **Found in /usr/share/perl/5.34/pod/perlfaq6.pod**\n- **Found in /usr/share/perl/5.34/pod/perlfaq8.pod**\n- **Found in /usr/share/perl/5.34/pod/perlfaq9.pod**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n"
        }
    ],
    "structuredContent": {
        "command": "make",
        "section": "-q",
        "mode": "perldoc",
        "summary": null,
        "synopsis": null,
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [],
        "examples": [],
        "see_also": [],
        "section_outline": [
            {
                "name": "Found in /usr/share/perl/5.34/pod/perlfaq2.pod",
                "lines": 6,
                "subsections": []
            },
            {
                "name": "Found in /usr/share/perl/5.34/pod/perlfaq3.pod",
                "lines": 189,
                "subsections": []
            },
            {
                "name": "Found in /usr/share/perl/5.34/pod/perlfaq4.pod",
                "lines": 37,
                "subsections": []
            },
            {
                "name": "Found in /usr/share/perl/5.34/pod/perlfaq5.pod",
                "lines": 95,
                "subsections": []
            },
            {
                "name": "Found in /usr/share/perl/5.34/pod/perlfaq6.pod",
                "lines": 6,
                "subsections": []
            },
            {
                "name": "Found in /usr/share/perl/5.34/pod/perlfaq8.pod",
                "lines": 8,
                "subsections": []
            },
            {
                "name": "Found in /usr/share/perl/5.34/pod/perlfaq9.pod",
                "lines": 32,
                "subsections": []
            }
        ],
        "sections": {
            "Found in /usr/share/perl/5.34/pod/perlfaq2.pod": {
                "content": "I grabbed the sources and tried to compile but gdbm/dynamic loading/malloc/linking/... failed. How do I make it work?\nRead the INSTALL file, which is part of the source distribution. It\ndescribes in detail how to cope with most idiosyncrasies that the\n\"Configure\" script can't work around for any given system or\narchitecture.\n",
                "subsections": []
            },
            "Found in /usr/share/perl/5.34/pod/perlfaq3.pod": {
                "content": "How can I make my Perl program run faster?\nThe best way to do this is to come up with a better algorithm. This can\noften make a dramatic difference. Jon Bentley's book *Programming\nPearls* (that's not a misspelling!) has some good tips on optimization,\ntoo. Advice on benchmarking boils down to: benchmark and profile to make\nsure you're optimizing the right part, look for better algorithms\ninstead of microtuning your code, and when all else fails consider just\nbuying faster hardware. You will probably want to read the answer to the\nearlier question \"How do I profile my Perl programs?\" if you haven't\ndone so already.\n\nA different approach is to autoload seldom-used Perl code. See the\nAutoSplit and AutoLoader modules in the standard distribution for that.\nOr you could locate the bottleneck and think about writing just that\npart in C, the way we used to take bottlenecks in C code and write them\nin assembler. Similar to rewriting in C, modules that have critical\nsections can be written in C (for instance, the PDL module from CPAN).\n\nIf you're currently linking your perl executable to a shared *libc.so*,\nyou can often gain a 10-25% performance benefit by rebuilding it to link\nwith a static libc.a instead. This will make a bigger perl executable,\nbut your Perl programs (and programmers) may thank you for it. See the\nINSTALL file in the source distribution for more information.\n\nThe undump program was an ancient attempt to speed up Perl program by\nstoring the already-compiled form to disk. This is no longer a viable\noption, as it only worked on a few architectures, and wasn't a good\nsolution anyway.\n\nHow can I make my Perl program take less memory?\nWhen it comes to time-space tradeoffs, Perl nearly always prefers to\nthrow memory at a problem. Scalars in Perl use more memory than strings\nin C, arrays take more than that, and hashes use even more. While\nthere's still a lot to be done, recent releases have been addressing\nthese issues. For example, as of 5.004, duplicate hash keys are shared\namongst all hashes using them, so require no reallocation.\n\nIn some cases, using substr() or vec() to simulate arrays can be highly\nbeneficial. For example, an array of a thousand booleans will take at\nleast 20,000 bytes of space, but it can be turned into one 125-byte bit\nvector--a considerable memory savings. The standard Tie::SubstrHash\nmodule can also help for certain types of data structure. If you're\nworking with specialist data structures (matrices, for instance) modules\nthat implement these in C may use less memory than equivalent Perl\nmodules.\n\nAnother thing to try is learning whether your Perl was compiled with the\nsystem malloc or with Perl's builtin malloc. Whichever one it is, try\nusing the other one and see whether this makes a difference. Information\nabout malloc is in the INSTALL file in the source distribution. You can\nfind out whether you are using perl's malloc by typing \"perl\n-V:usemymalloc\".\n\nOf course, the best way to save memory is to not do anything to waste it\nin the first place. Good programming practices can go a long way toward\nthis:\n\nDon't slurp!\nDon't read an entire file into memory if you can process it line by\nline. Or more concretely, use a loop like this:\n\n#\n# Good Idea\n#\nwhile (my $line = <$filehandle>) {\n# ...\n}\n\ninstead of this:\n\n#\n# Bad Idea\n#\nmy @data = <$filehandle>;\nforeach (@data) {\n# ...\n}\n\nWhen the files you're processing are small, it doesn't much matter\nwhich way you do it, but it makes a huge difference when they start\ngetting larger.\n\nUse map and grep selectively\nRemember that both map and grep expect a LIST argument, so doing\nthis:\n\n@wanted = grep {/pattern/} <$filehandle>;\n\nwill cause the entire file to be slurped. For large files, it's\nbetter to loop:\n\nwhile (<$filehandle>) {\npush(@wanted, $) if /pattern/;\n}\n\nAvoid unnecessary quotes and stringification\nDon't quote large strings unless absolutely necessary:\n\nmy $copy = \"$largestring\";\n\nmakes 2 copies of $largestring (one for $copy and another for the\nquotes), whereas\n\nmy $copy = $largestring;\n\nonly makes one copy.\n\nDitto for stringifying large arrays:\n\n{\nlocal $, = \"\\n\";\nprint @bigarray;\n}\n\nis much more memory-efficient than either\n\nprint join \"\\n\", @bigarray;\n\nor\n\n{\nlocal $\" = \"\\n\";\nprint \"@bigarray\";\n}\n\nPass by reference\nPass arrays and hashes by reference, not by value. For one thing,\nit's the only way to pass multiple lists or hashes (or both) in a\nsingle call/return. It also avoids creating a copy of all the\ncontents. This requires some judgement, however, because any changes\nwill be propagated back to the original data. If you really want to\nmangle (er, modify) a copy, you'll have to sacrifice the memory\nneeded to make one.\n\nTie large variables to disk\nFor \"big\" data stores (i.e. ones that exceed available memory)\nconsider using one of the DB modules to store it on disk instead of\nin RAM. This will incur a penalty in access time, but that's\nprobably better than causing your hard disk to thrash due to massive\nswapping.\n\nHow can I make my CGI script more efficient?\nBeyond the normal measures described to make general Perl programs\nfaster or smaller, a CGI program has additional issues. It may be run\nseveral times per second. Given that each time it runs it will need to\nbe re-compiled and will often allocate a megabyte or more of system\nmemory, this can be a killer. Compiling into C isn't going to help you\nbecause the process start-up overhead is where the bottleneck is.\n\nThere are three popular ways to avoid this overhead. One solution\ninvolves running the Apache HTTP server (available from\n<http://www.apache.org/> ) with either of the modperl or modfastcgi\nplugin modules.\n\nWith modperl and the Apache::Registry module (distributed with\nmodperl), httpd will run with an embedded Perl interpreter which\npre-compiles your script and then executes it within the same address\nspace without forking. The Apache extension also gives Perl access to\nthe internal server API, so modules written in Perl can do just about\nanything a module written in C can. For more on modperl, see\n<http://perl.apache.org/>\n\nWith the FCGI module (from CPAN) and the modfastcgi module (available\nfrom <http://www.fastcgi.com/> ) each of your Perl programs becomes a\npermanent CGI daemon process.\n\nFinally, Plack is a Perl module and toolkit that contains PSGI\nmiddleware, helpers and adapters to web servers, allowing you to easily\ndeploy scripts which can continue running, and provides flexibility with\nregards to which web server you use. It can allow existing CGI scripts\nto enjoy this flexibility and performance with minimal changes, or can\nbe used along with modern Perl web frameworks to make writing and\ndeploying web services with Perl a breeze.\n\nThese solutions can have far-reaching effects on your system and on the\nway you write your CGI programs, so investigate them with care.\n\nSee also\n<http://www.cpan.org/modules/by-category/15WorldWideWebHTMLHTTPCGI\n/> .\n\nWhat's MakeMaker?\n(contributed by brian d foy)\n\nThe ExtUtils::MakeMaker module, better known simply as \"MakeMaker\",\nturns a Perl script, typically called \"Makefile.PL\", into a Makefile.\nThe Unix tool \"make\" uses this file to manage dependencies and actions\nto process and install a Perl distribution.\n",
                "subsections": []
            },
            "Found in /usr/share/perl/5.34/pod/perlfaq4.pod": {
                "content": "Why don't my tied hashes make the defined/exists distinction?\nThis depends on the tied hash's implementation of EXISTS(). For example,\nthere isn't the concept of undef with hashes that are tied to DBM*\nfiles. It also means that exists() and defined() do the same thing with\na DBM* file, and what they end up doing is not what they do with\nordinary hashes.\n\nHow can I make my hash remember the order I put elements into it?\nUse the Tie::IxHash from CPAN.\n\nuse Tie::IxHash;\n\ntie my %myhash, 'Tie::IxHash';\n\nfor (my $i=0; $i<20; $i++) {\n$myhash{$i} = 2*$i;\n}\n\nmy @keys = keys %myhash;\n# @keys = (0,1,2,3,...)\n\nHow can I make the Perl equivalent of a C structure/C++ class/hash or array of hashes or arrays?\nUsually a hash ref, perhaps like this:\n\n$record = {\nNAME   => \"Jason\",\nEMPNO  => 132,\nTITLE  => \"deputy peon\",\nAGE    => 23,\nSALARY => 37000,\nPALS   => [ \"Norbert\", \"Rhys\", \"Phineas\"],\n};\n\nReferences are documented in perlref and perlreftut. Examples of complex\ndata structures are given in perldsc and perllol. Examples of structures\nand object-oriented classes are in perlootut.\n",
                "subsections": []
            },
            "Found in /usr/share/perl/5.34/pod/perlfaq5.pod": {
                "content": "How do I make a temporary file name?\nIf you don't need to know the name of the file, you can use \"open()\"\nwith \"undef\" in place of the file name. In Perl 5.8 or later, the\n\"open()\" function creates an anonymous temporary file:\n\nopen my $tmp, '+>', undef or die $!;\n\nOtherwise, you can use the File::Temp module.\n\nuse File::Temp qw/ tempfile tempdir /;\n\nmy $dir = tempdir( CLEANUP => 1 );\n($fh, $filename) = tempfile( DIR => $dir );\n\n# or if you don't need to know the filename\n\nmy $fh = tempfile( DIR => $dir );\n\nThe File::Temp has been a standard module since Perl 5.6.1. If you don't\nhave a modern enough Perl installed, use the \"newtmpfile\" class method\nfrom the IO::File module to get a filehandle opened for reading and\nwriting. Use it if you don't need to know the file's name:\n\nuse IO::File;\nmy $fh = IO::File->newtmpfile()\nor die \"Unable to make new temporary file: $!\";\n\nIf you're committed to creating a temporary file by hand, use the\nprocess ID and/or the current time-value. If you need to have many\ntemporary files in one process, use a counter:\n\nBEGIN {\nuse Fcntl;\nuse File::Spec;\nmy $tempdir  = File::Spec->tmpdir();\nmy $filebase = sprintf \"%d-%d-0000\", $$, time;\nmy $basename = File::Spec->catfile($tempdir, $filebase);\n\nsub tempfile {\nmy $fh;\nmy $count = 0;\nuntil( defined(fileno($fh)) || $count++ > 100 ) {\n$basename =~ s/-(\\d+)$/\"-\" . (1 + $1)/e;\n# OEXCL is required for security reasons.\nsysopen $fh, $basename, OWRONLY|OEXCL|OCREAT;\n}\n\nif( defined fileno($fh) ) {\nreturn ($fh, $basename);\n}\nelse {\nreturn ();\n}\n}\n}\n\nHow can I make a filehandle local to a subroutine? How do I pass filehandles between subroutines? How do I make an array of filehandles?\nAs of perl5.6, open() autovivifies file and directory handles as\nreferences if you pass it an uninitialized scalar variable. You can then\npass these references just like any other scalar, and use them in the\nplace of named handles.\n\nopen my    $fh, $filename;\n\nopen local $fh, $filename;\n\nprint $fh \"Hello World!\\n\";\n\nprocessfile( $fh );\n\nIf you like, you can store these filehandles in an array or a hash. If\nyou access them directly, they aren't simple scalars and you need to\ngive \"print\" a little help by placing the filehandle reference in\nbraces. Perl can only figure it out on its own when the filehandle\nreference is a simple scalar.\n\nmy @fhs = ( $fh1, $fh2, $fh3 );\n\nfor( $i = 0; $i <= $#fhs; $i++ ) {\nprint {$fhs[$i]} \"just another Perl answer, \\n\";\n}\n\nBefore perl5.6, you had to deal with various typeglob idioms which you\nmay see in older code.\n\nopen FILE, \"> $filename\";\nprocesstypeglob(   *FILE );\nprocessreference( \\*FILE );\n\nsub processtypeglob  { local *FH = shift; print FH  \"Typeglob!\" }\nsub processreference { local $fh = shift; print $fh \"Reference!\" }\n\nIf you want to create many anonymous handles, you should check out the\nSymbol or IO::Handle modules.\n",
                "subsections": []
            },
            "Found in /usr/share/perl/5.34/pod/perlfaq6.pod": {
                "content": "How can I make \"\\w\" match national character sets?\nPut \"use locale;\" in your script. The \\w character class is taken from\nthe current locale.\n\nSee perllocale for details.\n",
                "subsections": []
            },
            "Found in /usr/share/perl/5.34/pod/perlfaq8.pod": {
                "content": "How do I make a system() exit on control-C?\nYou can't. You need to imitate the \"system()\" call (see perlipc for\nsample code) and then have a signal handler for the INT signal that\npasses the signal on to the subprocess. Or you can check for it:\n\n$rc = system($cmd);\nif ($rc & 127) { die \"signal death\" }\n",
                "subsections": []
            },
            "Found in /usr/share/perl/5.34/pod/perlfaq9.pod": {
                "content": "How do I make sure users can't enter values into a form that causes my CGI script to do bad things?\n(contributed by brian d foy)\n\nYou can't prevent people from sending your script bad data. Even if you\nadd some client-side checks, people may disable them or bypass them\ncompletely. For instance, someone might use a module such as LWP to\nsubmit to your web site. If you want to prevent data that try to use SQL\ninjection or other sorts of attacks (and you should want to), you have\nto not trust any data that enter your program.\n\nThe perlsec documentation has general advice about data security. If you\nare using the DBI module, use placeholder to fill in data. If you are\nrunning external programs with \"system\" or \"exec\", use the list forms.\nThere are many other precautions that you should take, too many to list\nhere, and most of them fall under the category of not using any data\nthat you don't intend to use. Trust no one.\n\nHow do I use MIME to make an attachment to a mail message?\nEmail::MIME directly supports multipart messages. Email::MIME objects\nthemselves are parts and can be attached to other Email::MIME objects.\nConsult the Email::MIME documentation for more information, including\nall of the supported methods and examples of their use.\n\nEmail::Stuffer uses Email::MIME under the hood to construct messages,\nand wraps the most common attachment tasks with the simple \"attach\" and\n\"attachfile\" methods.\n\nEmail::Stuffer->to('friend@example.com')\n->subject('The file')\n->attachfile('stuff.csv')\n->sendordie;\n",
                "subsections": []
            }
        }
    }
}