Free find 5.8.8 software for linux

File::Find is a Perl module to traverse a directory tree.

SYNOPSIS

use File::Find;
find(&wanted, @directories_to_search);
sub wanted { ... }

use File::Find;
finddepth(&wanted, @directories_to_search);
sub wanted { ... }

use File::Find;
find({ wanted => &process, follow => 1 }, .);

These are functions for searching through directory trees doing work on each file found similar to the Unix find command. File::Find exports two functions, find and finddepth. They work similarly but have subtle differences.

find

find(&wanted, @directories);
find(%options, @directories);

find() does a depth-first search over the given @directories in the order they are given. For each file or directory found, it calls the &wanted subroutine. (See below for details on how to use the &wanted function). Additionally, for each directory found, it will chdir() into that directory and continue the search, invoking the &wanted function on each file or subdirectory in the directory.

finddepth

finddepth(&wanted, @directories);
finddepth(%options, @directories);

finddepth() works just like find() except that is invokes the &wanted function for a directory after invoking it for the directorys contents. It does a postorder traversal instead of a preorder traversal, working from the bottom of the directory tree up where find() works from the top of the tree down.

Fcntl is a Perl module to load the C Fcntl.h defines.

SYNOPSIS

use Fcntl;
use Fcntl qw(:DEFAULT :flock);

This module is just a translation of the C fcntl.h file. Unlike the old mechanism of requiring a translated fcntl.ph file, this uses the h2xs program (see the Perl source distribution) and your native C compiler. This means that it has a far more likely chance of getting the numbers right.

NOTE

Only #define symbols get translated; you must still correctly pack up your own arguments to pass as args for locking functions, etc.

EXPORTED SYMBOLS

By default your systems F_* and O_* constants (eg, F_DUPFD and O_CREAT) and the FD_CLOEXEC constant are exported into your namespace.

You can request that the flock() constants (LOCK_SH, LOCK_EX, LOCK_NB and LOCK_UN) be provided by using the tag :flock. See Exporter.

You can request that the old constants (FAPPEND, FASYNC, FCREAT, FDEFER, FEXCL, FNDELAY, FNONBLOCK, FSYNC, FTRUNC) be provided for compatibility reasons by using the tag :Fcompat. For new applications the newer versions of these constants are suggested (O_APPEND, O_ASYNC, O_CREAT, O_DEFER, O_EXCL, O_NDELAY, O_NONBLOCK, O_SYNC, O_TRUNC).

For ease of use also the SEEK_* constants (for seek() and sysseek(), e.g. SEEK_END) and the S_I* constants (for chmod() and stat()) are available for import. They can be imported either separately or using the tags :seek and :mode.

Please refer to your native fcntl(2), open(2), fseek(3), lseek(2) (equal to Perls seek() and sysse

FileCache is a Perl module to keep more files open than the system permits.

SYNOPSIS

use FileCache;
# or
use FileCache maxopen => 16;

cacheout $mode, $path;
# or
cacheout $path;
print $path @data;

$fh = cacheout $mode, $path;
# or
$fh = cacheout $path;
print $fh @data;

The cacheout function will make sure that theres a filehandle open for reading or writing available as the pathname you give it. It automatically closes and re-opens files if you exceed your systems maximum number of file descriptors, or the suggested maximum maxopen.

cacheout EXPR

The 1-argument form of cacheout will open a file for writing (>) on its first use, and appending (>>) thereafter.

Returns EXPR on success for convenience. You may neglect the return value and manipulate EXPR as the filehandle directly if you prefer.

cacheout MODE, EXPR

The 2-argument form of cacheout will use the supplied mode for the initial and subsequent openings. Most valid modes for 3-argument open are supported namely; >, +>, , |- and -|

To pass supplemental arguments to a program opened with |- or -| append them to the command string as you would system EXPR.

Returns EXPR on success for convenience. You may neglect the return value and manipulate EXPR as the filehandle directly if you prefer.

CAVEATS

While it is permissible to close a FileCache managed file, do not do so if you are calling FileCache::cacheout from a package other than which it was imported, or with another module which overrides close. If you must, use FileCache::cacheout_close.

Although FileCache can be used with piped opens (-| or |-) doing so is strongly discouraged. If FileCache finds it necessary to close and then reopen a pipe, the command at the far end of the pipe will be reexecuted - the results of performing IO on FileCached pipes is unlikely to be what you expect.

The ability to use FileCache on pipes may be removed in a future release.
FileCache does not store the current file offset if it finds it necessary to close a file. When the file is reopened, the offset will be as specified by the original open file mode. This could be construed to be a bug.

ODBM_File is a Perl module to allow tied access to odbm files.

SYNOPSIS

use Fcntl; # For O_RDWR, O_CREAT, etc.
use ODBM_File;

# Now read and change the hash
$h{newkey} = newvalue;
print $h{oldkey};
...

untie %h;

ODBM_File establishes a connection between a Perl hash variable and a file in ODBM_File format;. You can manipulate the data in the file just as if it were in a Perl hash, but when your program exits, the data will remain in the file, to be used the next time your program runs.

Use ODBM_File with the Perl built-in tie function to establish the connection between the variable and the file. The arguments to tie should be:

The hash variable you want to tie.

The string "ODBM_File". (Ths tells Perl to use the ODBM_File package to perform the functions of the hash.)

The name of the file you want to tie to the hash.

Flags. Use one of:

O_RDONLY

Read-only access to the data in the file.

O_WRONLY

Write-only access to the data in the file.

O_RDWR

Both read and write access.

If you want to create the file if it does not exist, add O_CREAT to any of these, as in the example. If you omit O_CREAT and the file does not already exist, the tie call will fail.

The default permissions to use if a new file is created. The actual permissions will be modified by the users umask, so you should probably use 0666 here. (See "umask" in perlfunc.)

SelfLoader is a Perl module created to load functions only on demand.

SYNOPSIS

package FOOBAR;
use SelfLoader;

... (initializing code)

__DATA__
sub {....

This module tells its users that functions in the FOOBAR package are to be autoloaded from after the __DATA__ token. See also "Autoloading" in perlsub.

The __DATA__ token

The __DATA__ token tells the perl compiler that the perl code for compilation is finished. Everything after the __DATA__ token is available for reading via the filehandle FOOBAR::DATA, where FOOBAR is the name of the current package when the __DATA__ token is reached. This works just the same as __END__ does in package main, but for other modules data after __END__ is not automatically retrievable, whereas data after __DATA__ is. The __DATA__ token is not recognized in versions of perl prior to 5.001m.

Note that it is possible to have __DATA__ tokens in the same package in multiple files, and that the last __DATA__ token in a given package that is encountered by the compiler is the one accessible by the filehandle. This also applies to __END__ and main, i.e. if the main program has an __END__, but a module required (_not_ used) by that program has a package main; declaration followed by an __DATA__, then the DATA filehandle is set to access the data after the __DATA__ in the module, _not_ the data after the __END__ token in the main program, since the compiler encounters the required file later.

SelfLoader autoloading

The SelfLoader works by the user placing the __DATA__ token after perl code which needs to be compiled and run at require time, but before subroutine declarations that can be loaded in later - usually because they may never be called.

The SelfLoader will read from the FOOBAR::DATA filehandle to load in the data after __DATA__, and load in any subroutine when it is called. The costs are the one-time parsing of the data after __DATA__, and a load delay for the _first_ call of any autoloaded function. The benefits (hopefully) are a speeded up compilation phase, with no need to load functions which are never used.
The SelfLoader will stop reading from __DATA__ if it encounters the __END__ token - just as you would expect. If the __END__ token is present, and is followed by the token DATA, then the SelfLoader leaves the FOOBAR::DATA filehandle open on the line after that token.

The SelfLoader exports the AUTOLOAD subroutine to the package using the SelfLoader, and this loads the called subroutine when it is first called.
There is no advantage to putting subroutines which will _always_ be called after the __DATA__ token.

Autoloading and package lexicals

A my $pack_lexical statement makes the variable $pack_lexical local _only_ to the file up to the __DATA__ token. Subroutines declared elsewhere _cannot_ see these types of variables, just as if you declared subroutines in the package but in another file, they cannot see these variables.

So specifically, autoloaded functions cannot see package lexicals (this applies to both the SelfLoader and the Autoloader). The vars pragma provides an alternative to defining package-level globals that will be visible to autoloaded routines. See the documentation on vars in the pragma section of perlmod.

SelfLoader and AutoLoader

The SelfLoader can replace the AutoLoader - just change use AutoLoader to use SelfLoader (though note that the SelfLoader exports the AUTOLOAD function - but if you have your own AUTOLOAD and are using the AutoLoader too, you probably know what youre doing), and the __END__ token to __DATA__. You will need perl version 5.001m or later to use this (version 5.001 with all patches up to patch m).

There is no need to inherit from the SelfLoader.

The SelfLoader works similarly to the AutoLoader, but picks up the subs from after the __DATA__ instead of in the lib/auto directory. There is a maintenance gain in not needing to run AutoSplit on the module at installation, and a runtime gain in not needing to keep opening and closing files to load subs. There is a runtime loss in needing to parse the code after the __DATA__. Details of the AutoLoader and another view of these distinctions can be found in that modules documentation.

__DATA__, __END__, and the FOOBAR::DATA filehandle.

This section is only relevant if you want to use the FOOBAR::DATA together with the SelfLoader.

Data after the __DATA__ token in a module is read using the FOOBAR::DATA filehandle. __END__ can still be used to denote the end of the __DATA__ section if followed by the token DATA - this is supported by the SelfLoader. The FOOBAR::DATA filehandle is left open if an __END__ followed by a DATA is found, with the filehandle positioned at the start of the line after the __END__ token. If no __END__ token is present, or an __END__ token with no DATA token on the same line, then the filehandle is closed.

The SelfLoader reads from wherever the current position of the FOOBAR::DATA filehandle is, until the EOF or __END__. This means that if you want to use that filehandle (and ONLY if you want to), you should either

1. Put all your subroutine declarations immediately after the __DATA__ token and put your own data after those declarations, using the __END__ token to mark the end of subroutine declarations. You must also ensure that the SelfLoader reads first by calling SelfLoader->load_stubs();, or by using a function which is selfloaded;
or
2. You should read the FOOBAR::DATA filehandle first, leaving the handle open and positioned at the first line of subroutine declarations.
You could conceivably do both.

Classes and inherited methods.

For modules which are not classes, this section is not relevant. This section is only relevant if you have methods which could be inherited.

A subroutine stub (or forward declaration) looks like

sub stub;

i.e. it is a subroutine declaration without the body of the subroutine. For modules which are not classes, there is no real need for stubs as far as autoloading is concerned.

For modules which ARE classes, and need to handle inherited methods, stubs are needed to ensure that the method inheritance mechanism works properly. You can load the stubs into the module at require time, by adding the statement SelfLoader->load_stubs(); to the module to do this.

The alternative is to put the stubs in before the __DATA__ token BEFORE releasing the module, and for this purpose the Devel::SelfStubber module is available. However this does require the extra step of ensuring that the stubs are in the module. If this is done I strongly recommend that this is done BEFORE releasing the module - it should NOT be done at install time in general.

Multiple packages and fully qualified subroutine names

Subroutines in multiple packages within the same file are supported - but you should note that this requires exporting the SelfLoader::AUTOLOAD to every package which requires it. This is done automatically by the SelfLoader when it first loads the subs into the cache, but you should really specify it in the initialization before the __DATA__ by putting a use SelfLoader statement in each package.

Fully qualified subroutine names are also supported. For example,

__DATA__
sub foo::bar {23}
package baz;
sub dob {32}

will all be loaded correctly by the SelfLoader, and the SelfLoader will ensure that the packages foo and baz correctly have the SelfLoader AUTOLOAD method when the data after __DATA__ is first parsed.

File::Glob is a Perl extension for BSD glob routine.

SYNOPSIS

use File::Glob :glob;

@list = bsd_glob(*.[ch]);
$homedir = bsd_glob(~gnat, GLOB_TILDE | GLOB_ERR);

if (GLOB_ERROR) {
# an error occurred reading $homedir
}

## override the core glob (CORE::glob() does this automatically
## by default anyway, since v5.6.0)
use File::Glob :globally;
my @sources = ;

## override the core glob, forcing case sensitivity
use File::Glob qw(:globally :case);
my @sources = ;

## override the core glob forcing case insensitivity
use File::Glob qw(:globally :nocase);
my @sources = ;

## glob on all files in home directory
use File::Glob :globally;
my @sources = ;

The glob angle-bracket operator is a pathname generator that implements the rules for file name pattern matching used by Unix-like shells such as the Bourne shell or C shell.
File::Glob::bsd_glob() implements the FreeBSD glob(3) routine, which is a superset of the POSIX glob() (described in IEEE Std 1003.2 "POSIX.2"). bsd_glob() takes a mandatory pattern argument, and an optional flags argument, and returns a list of filenames matching the pattern, with interpretation of the pattern modified by the flags variable.

Since v5.6.0, Perls CORE::glob() is implemented in terms of bsd_glob(). Note that they dont share the same prototype--CORE::glob() only accepts a single argument. Due to historical reasons, CORE::glob() will also split its argument on whitespace, treating it as multiple patterns, whereas bsd_glob() considers them as one pattern.

c2ph, pstruct is a Perl module that can dump C structures as generated from cc -g -S stabs.

SYNOPSIS

c2ph [-dpnP] [var=val] [files ...]

OPTIONS

Options:

-w wide; short for: type_width=45 member_width=35 offset_width=8
-x hex; short for: offset_fmt=x offset_width=08 size_fmt=x size_width=04

-n do not generate perl code (default when invoked as pstruct)
-p generate perl code (default when invoked as c2ph)
-v generate perl code, with C decls as comments

-i do NOT recompute sizes for intrinsic datatypes
-a dump information on intrinsics also

-t trace execution
-d spew reams of debugging output

-slist give comma-separated list a structures to dump

Once upon a time, I wrote a program called pstruct. It was a perl program that tried to parse out C structures and display their member offsets for you. This was especially useful for people looking at binary dumps or poking around the kernel.

Pstruct was not a pretty program. Neither was it particularly robust. The problem, you see, was that the C compiler was much better at parsing C than I could ever hope to be.

So I got smart: I decided to be lazy and let the C compiler parse the C, which would spit out debugger stabs for me to read. These were much easier to parse. Its still not a pretty program, but at least its more robust.

B::C is Perl compilers C backend.

SYNOPSIS

perl -MO=C[,OPTIONS] foo.pl

This compiler backend takes Perl source and generates C source code corresponding to the internal structures that perl uses to run your program. When the generated C source is compiled and run, it cuts out the time which perl would have taken to load and parse your program into its internal semi-compiled form. That means that compiling with this backend will not help improve the runtime execution speed of your program but may improve the start-up time. Depending on the environment in which your program runs this may be either a help or a hindrance.

OPTIONS

If there are any non-option arguments, they are taken to be names of objects to be saved (probably doesnt work properly yet). Without extra arguments, it saves the main program.

-ofilename

Output to filename instead of STDOUT

-v

Verbose compilation (currently gives a few compilation statistics).

--

Force end of options

-uPackname

Force apparently unused subs from package Packname to be compiled. This allows programs to use eval "foo()" even when sub foo is never seen to be used at compile time. The down side is that any subs which really are never used also have code generated. This option is necessary, for example, if you have a signal handler foo which you initialise with $SIG{BAR} = "foo". A better fix, though, is just to change it to $SIG{BAR} = &foo. You can have multiple -u options. The compiler tries to figure out which packages may possibly have subs in which need compiling but the current version doesnt do it very well. In particular, it is confused by nested packages (i.e. of the form A::B) where package A does not contain any subs.

-D

Debug options (concatenated or separate flags like perl -D).

-Do

OPs, prints each OP as its processed

-Dc

COPs, prints COPs as processed (incl. file & line num)

-DA

prints AV information on saving

-DC

prints CV information on saving

-DM

prints MAGIC information on saving

-f

Force options/optimisations on or off one at a time. You can explicitly disable an option using -fno-option. All options default to disabled.

-fcog

Copy-on-grow: PVs declared and initialised statically.

-fsave-data

Save package::DATA filehandles ( only available with PerlIO ).

-fppaddr

Optimize the initialization of op_ppaddr.

-fwarn-sv

Optimize the initialization of cop_warnings.

-fuse-script-name

Use the script name instead of the program name as $0.

-fsave-sig-hash

Save compile-time modifications to the %SIG hash.

-On

Optimisation level (n = 0, 1, 2, ...). -O means -O1.

-O0

Disable all optimizations.

-O1

Enable -fcog.

-O2

Enable -fppaddr, -fwarn-sv.

-llimit

Some C compilers impose an arbitrary limit on the length of string constants (e.g. 2048 characters for Microsoft Visual C++). The -llimit options tells the C backend not to generate string literals exceeding that limit.