When Using Cpan in Linux Ubuntu Should I Run It Using Sudo/As Root or as My Default User

when using CPAN in linux ubuntu should I run it using sudo / as root or as my default user

You should run the cpan command as your normal user. You have two choices:

1. Install modules into a directory under your home dir. local::lib will help you set that up.

2. Configure cpan to use sudo during the install phase. You do that by starting the cpan shell and typing:

   o conf make_install_make_command 'sudo make'
   o conf mbuild_install_build_command 'sudo ./Build'
   o conf commit
   

   The first line configures MakeMaker to use sudo. The second line does the same for Module::Build. The third line saves the changes.

CPAN first launching configuration

If you use sudo, CPAN will use root to install the libraries in a central location where all users on the machine can access the files without any special configuration. If you use 'local::lib', it will create a library in your home directory and install the modules such that only perl programs that have been configured to look for modules in your home directory will find the modules.

Perl uses the special variable @INC to search for module paths. So you can install modules anywhere as long as you set @INC properly before you use them. This article explains the basics.

http://www.symkat.com/find-a-perl-modules-path

You can do all kinds of fun stuff with @INC; one of my favorite hacks it to put a function pointer in there and use custom perl code to lookup modules.

Perl not recognizing module / module path for root user

These are the commands that ended up working for me. I corrupted my first environment with local::lib / non-sudo cpan install, so I setup a fresh VM.

sudo apt install make
sudo apt install build-essential
sudo apt install libmysqlclient-dev
sudo cpan App::cpanminus
cpanm --sudo DBI
cpanm --sudo Array::Utils
cpanm --sudo DBD::mysql

cpan install switch failed

You are doing everything right, but Switch is broken on Perl 5.13.3 and above. The maintainers of the modules know about the issue, and are seemingly uninterested in fixing it. Given the poor maintenance of the module, even if you did persuade it to install, it wouldn't seem advisable to use it in production code.

A couple of recent relevant discussions on PerlMonks discussing switch-like constructs:

• Smartmatch alternatives
• perldata unclear on 'given's fate

---

Related Topics