Anything by Mark Sobell. He does a sort of theme-and-variations for various flavours of unix, so pick the book most appropriate to the environment in hand. The books are quite good. One of his was a prescribed text when I did my B.Sc.
Some of these books have been in print for quite a while and are still relevant. Consequently they are also often available secondhand at much less than list price. Amazon marketplace is a good place to look for such items. It's quite a good way to do a shotgun approach to topics like this for not much money.
As an example, in New Zealand technical books are usurously expensive due to a weak kiwi peso (as the $NZ is affectionately known in expat circles) and a tortuously long supply chain. You could spend 20% of a week's after-tax pay for a starting graduate on a single book. When I was living there just out of university I used this type of market a lot, often buying books for 1/4 of their list price - including the cost of shipping to New Zealand. If you're not living in a location with tier-1 incomes I recommend this.
E-Books and on-line resources (thanks to israkir for reminding me):
The Linux Documentation project (www.tldp.org), has many specific topic guides known as HowTos that also often concern third party OSS tools and will be relevant to other Unix variants. It also has a series of FAQ's and guides.
Unix Guru's Universe is a collection of unix resources with a somewhat more old-school flavour.
Google. There are many, many unix and linux resources on the web. Search strings like unix commands or learn unix will turn up any amount of online resources.
Safari. This is a subscription service, but you can search the texts of quite a large number of books. I can recommend this as I've used it. They also do site licences for corporate customers.
Some of the philosophy of Unix:
The Art of UNIX Programming by E S Raymond (available online and in print).
The Practice of Programming by B W Kernighan and R Pike.
We will look at how the contents of this array are constructed and can be manipulated to affect where the Perl interpreter will find the module files.
Default @INC
Perl interpreter is compiled with a specific @INC default value. To find out this value, run env -i perl -V command (env -i ignores the PERL5LIB environmental variable - see #2) and in the output you will see something like this:
Perl pre-pends @INC with a list of directories (colon-separated) contained in PERL5LIB (if it is not defined, PERLLIB is used) environment variable of your shell. To see the contents of @INC after PERL5LIB and PERLLIB environment variables have taken effect, run perl -V.
Perl pre-pends @INC with a list of directories (colon-separated) passed as value of the -I command-line option. This can be done in three ways, as usual with Perl options:
Pass it on command line:
perl -I /my/moduledir your_script.pl
Pass it via the first line (shebang) of your Perl script:
#!/usr/local/bin/perl -w -I /my/moduledir
Pass it as part of PERL5OPT (or PERLOPT) environment variable (see chapter 19.02 in Programming Perl)
Pass it via the lib pragma
Perl pre-pends @INC with a list of directories passed in to it via use lib.
In a program:
use lib ("/dir1", "/dir2");
On the command line:
perl -Mlib=/dir1,/dir2
You can also remove the directories from @INC via no lib.
You can directly manipulate @INC as a regular Perl array.
Note: Since @INC is used during the compilation phase, this must be done inside of a BEGIN {} block, which precedes the use MyModule statement.
Add directories to the beginning via unshift @INC, $dir.
Add directories to the end via push @INC, $dir.
Do anything else you can do with a Perl array.
Note: The directories are unshifted onto @INC in the order listed in this answer, e.g. default @INC is last in the list, preceded by PERL5LIB, preceded by -I, preceded by use lib and direct @INC manipulation, the latter two mixed in whichever order they are in Perl code.
References:
perldoc perlmod
perldoc lib
Perl Module Mechanics - a great guide containing practical HOW-TOs
How do I 'use' a Perl module in a directory not in @INC?
How does a Perl program know where to find the file containing Perl module it uses?
There does not seem to be a comprehensive @INC FAQ-type post on Stack Overflow, so this question is intended as one.
When to use each approach?
If the modules in a directory need to be used by many/all scripts on your site, especially run by multiple users, that directory should be included in the default @INC compiled into the Perl binary.
If the modules in the directory will be used exclusively by a specific user for all the scripts that user runs (or if recompiling Perl is not an option to change default @INC in previous use case), set the users' PERL5LIB, usually during user login.
Note: Please be aware of the usual Unix environment variable pitfalls - e.g. in certain cases running the scripts as a particular user does not guarantee running them with that user's environment set up, e.g. via su.
If the modules in the directory need to be used only in specific circumstances (e.g. when the script(s) is executed in development/debug mode, you can either set PERL5LIB manually, or pass the -I option to perl.
If the modules need to be used only for specific scripts, by all users using them, use use lib/no lib pragmas in the program itself. It also should be used when the directory to be searched needs to be dynamically determined during runtime - e.g. from the script's command line parameters or script's path (see the FindBin module for very nice use case).
If the directories in @INC need to be manipulated according to some complicated logic, either impossible to too unwieldy to implement by combination of use lib/no lib pragmas, then use direct @INC manipulation inside BEGIN {} block or inside a special purpose library designated for @INC manipulation, which must be used by your script(s) before any other modules are used.
An example of this is automatically switching between libraries in prod/uat/dev directories, with waterfall library pickup in prod if it's missing from dev and/or UAT (the last condition makes the standard "use lib + FindBin" solution fairly complicated.
A detailed illustration of this scenario is in How do I use beta Perl modules from beta Perl scripts?.
An additional use case for directly manipulating @INC is to be able to add subroutine references or object references (yes, Virginia, @INC can contain custom Perl code and not just directory names, as explained in When is a subroutine reference in @INC called?).
I've wiki'd this post - could those with sufficient rep add in items to it.
System administration, general usage books
Nemeth et. al, Linux System Administration
The Armadillo book, as mentioned by Bill The Lizard below.
Anything by Mark Sobell. He does a sort of theme-and-variations for various flavours of unix, so pick the book most appropriate to the environment in hand. The books are quite good. One of his was a prescribed text when I did my B.Sc.
Stevens' TCP/IP illustrated, vol. 1: The Protocols for a comprehensive run down on how TCP/IP works in detail.
I've never read this particular book, but many people here are recommending Unix Power Tools as mentioned by Hortitude.
Programming:
Anything by the late W. Richard Stevens, in particular Advanced Programming in the Unix Environment and Unix Network Programming Vol. 1 and vol. 2
Various classic c/unix books, such as The Unix Programming Environment, Advanced Unix Programming, Programming Pearls and of course K&R. The C/Unix books tend to go into the underlying architecture, and will give a fair degree of insight that's relevant across the board - these are the underlying mechanisms within the system. Anyone trying to do system-level programming (basically anything using system services, no matter what the language) will find a grounding in this to be beneficial.
Specific tools (e.g. Sendmail)
Various of the books from O'Reilly and other publishers cover specific topics. Some of the key ones are:
The Bat book on sendmail - if you have occasion to experience the joys of working with sendmail.cf. If you have a choice on MTA, postfix or qmail are somewhat easier to work with (I've been using postfix since about 2000). O'reilly publish guides to both of them.
Some classic works on perl: the Camel and Llama books (the latter written by none other than Randal Schwartz).
Sed and awk. Not sure what the critters on the cover are. My copy went south a while ago. While on the subject of this, Mastering Regular Expressions has also gotten a mention here and is a good book on the subject.
Samba. The hornbill (?) book covers this; there is also quite a lot of on-line documentation.
NFS/NIS for those using or maintaining unix or linux clients.
Some of these books have been in print for quite a while and are still relevant. Consequently they are also often available secondhand at much less than list price. Amazon marketplace is a good place to look for such items. It's quite a good way to do a shotgun approach to topics like this for not much money.
As an example, in New Zealand technical books are usurously expensive due to a weak kiwi peso (as the $NZ is affectionately known in expat circles) and a tortuously long supply chain. You could spend 20% of a week's after-tax pay for a starting graduate on a single book. When I was living there just out of university I used this type of market a lot, often buying books for 1/4 of their list price - including the cost of shipping to New Zealand. If you're not living in a location with tier-1 incomes I recommend this.
E-Books and on-line resources (thanks to israkir for reminding me):
The Linux Documentation project (www.tldp.org), has many specific topic guides known as HowTos that also often concern third party OSS tools and will be relevant to other Unix variants. It also has a series of FAQ's and guides.
Unix Guru's Universe is a collection of unix resources with a somewhat more old-school flavour.
Google. There are many, many unix and linux resources on the web. Search strings like unix commands or learn unix will turn up any amount of online resources.
Safari. This is a subscription service, but you can search the texts of quite a large number of books. I can recommend this as I've used it. They also do site licences for corporate customers.
Some of the philosophy of Unix:
The Art of UNIX Programming by E S Raymond (available online and in print).
The Practice of Programming by B W Kernighan and R Pike.
We will look at how the contents of this array are constructed and can be manipulated to affect where the Perl interpreter will find the module files.
Default
@INC
Perl interpreter is compiled with a specific
@INC
default value. To find out this value, runenv -i perl -V
command (env -i
ignores thePERL5LIB
environmental variable - see #2) and in the output you will see something like this:Note
.
at the end; this is the current directory. It is missing when Perl runs with-T
(taint checks enabled).To change the default path when configuring Perl binary compilation, set the configuration option
otherlibdirs
:Environmental variable
PERL5LIB
(orPERLLIB
)Perl pre-pends
@INC
with a list of directories (colon-separated) contained inPERL5LIB
(if it is not defined,PERLLIB
is used) environment variable of your shell. To see the contents of@INC
afterPERL5LIB
andPERLLIB
environment variables have taken effect, runperl -V
.-I
command-line optionPerl pre-pends
@INC
with a list of directories (colon-separated) passed as value of the-I
command-line option. This can be done in three ways, as usual with Perl options:Pass it on command line:
Pass it via the first line (shebang) of your Perl script:
Pass it as part of
PERL5OPT
(orPERLOPT
) environment variable (see chapter 19.02 in Programming Perl)Pass it via the
lib
pragmaPerl pre-pends
@INC
with a list of directories passed in to it viause lib
.In a program:
On the command line:
You can also remove the directories from
@INC
viano lib
.You can directly manipulate
@INC
as a regular Perl array.Note: Since
@INC
is used during the compilation phase, this must be done inside of aBEGIN {}
block, which precedes theuse MyModule
statement.Add directories to the beginning via
unshift @INC, $dir
.Add directories to the end via
push @INC, $dir
.Do anything else you can do with a Perl array.
Note: The directories are unshifted onto
@INC
in the order listed in this answer, e.g. default@INC
is last in the list, preceded byPERL5LIB
, preceded by-I
, preceded byuse lib
and direct@INC
manipulation, the latter two mixed in whichever order they are in Perl code.References:
@INC
?There does not seem to be a comprehensive
@INC
FAQ-type post on Stack Overflow, so this question is intended as one.When to use each approach?
If the modules in a directory need to be used by many/all scripts on your site, especially run by multiple users, that directory should be included in the default
@INC
compiled into the Perl binary.If the modules in the directory will be used exclusively by a specific user for all the scripts that user runs (or if recompiling Perl is not an option to change default
@INC
in previous use case), set the users'PERL5LIB
, usually during user login.Note: Please be aware of the usual Unix environment variable pitfalls - e.g. in certain cases running the scripts as a particular user does not guarantee running them with that user's environment set up, e.g. via
su
.If the modules in the directory need to be used only in specific circumstances (e.g. when the script(s) is executed in development/debug mode, you can either set
PERL5LIB
manually, or pass the-I
option to perl.If the modules need to be used only for specific scripts, by all users using them, use
use lib
/no lib
pragmas in the program itself. It also should be used when the directory to be searched needs to be dynamically determined during runtime - e.g. from the script's command line parameters or script's path (see the FindBin module for very nice use case).If the directories in
@INC
need to be manipulated according to some complicated logic, either impossible to too unwieldy to implement by combination ofuse lib
/no lib
pragmas, then use direct@INC
manipulation insideBEGIN {}
block or inside a special purpose library designated for@INC
manipulation, which must be used by your script(s) before any other modules are used.An example of this is automatically switching between libraries in prod/uat/dev directories, with waterfall library pickup in prod if it's missing from dev and/or UAT (the last condition makes the standard "use lib + FindBin" solution fairly complicated. A detailed illustration of this scenario is in How do I use beta Perl modules from beta Perl scripts?.
An additional use case for directly manipulating
@INC
is to be able to add subroutine references or object references (yes, Virginia,@INC
can contain custom Perl code and not just directory names, as explained in When is a subroutine reference in @INC called?).