o conf
[download]

not just conf. See h or help in your cpan shell.

Blimey - how daft do I feel...I thought the o was a bullet point!

It works now I type the correct things :)

As it is writing these to a config file, they are persistent are they?

See o conf commit and o conf auto_commit.
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

The magic command is o conf, not conf.

Personally, I would recommend going once through the setup of local::lib, which sets up CPAN_PREFIX and INSTALL_BASE properly.

The magic command is o conf, not conf.

*feeling daft*

According to CPAN's r command, I do not have local::lib installed.

Yes, I assumed so. Which is why I suggested that you install it and set it up :) See the bootstrapping technique to install it.

I misunderstood, believing that you have full control of your host. Reading your subsequent posts it seems you don't have this power and so you will have to abide to your provider's rules (like perhaps you wont be able to use the C compiler because they see it as a security threat). As a result, my suggestion that you install perlbrew may not solve your problems as it will introduce other walls because of your limited control. You can surely install perlbrew as normal user in your home-dir. And you may find a perl binary to install without the need of compilation. Perlbrew can incorporate that binary and manage it. Too much work perhaps for hitting a wall later (e.g. with installing modules which require a C compiler).

This may be helpful https://www.namecheap.com/support/knowledgebase/article.aspx/9693/29/how-to-install-perl-modules-on-shared-servers as it seems to describe your case and a remedy in a similar hosting environment. It is unclear whether following their instructions, even with the C compiler disabled, you can install XS modules which require it.

The question now is why cPanel does not allow you to install (some?) modules. Without me ever using cPanel or knowing what's going on in the mind of the hosting service I would guess that the answer is "because you can mess your system very easily". You see Perl is used for some of OS maintenance and if you even upgrade system Perl or a module that system Perl relies on to be on a particular version then some things may break.

But irrespective of me being correct in my guess, I would suggest that you install perlbrew (as root) and from within it your preferred Perl (e.g. the latest). Follow this guide: https://metacpan.org/pod/distribution/App-perlbrew/script/perlbrew#PERLBREW_ROOT on how to install it for many users (they have to modify their bashrc). The problem you will encounter is that your CGI scripts must be told exactly what Perl to use because they may be running under a custom user account (e.g. www). I am sure you will be able to find plenty of info on how to do this.

What is suggested in the above guide is that you create a 'perlbrew' user which has write permissions to perlbrew's home dir. And whenever you want to maintain perlbrew by upgrading perl or installing a module, you must do that as 'perlbrew' user.

So, now you have a Perl installed which is independent from system Perl (but not necessarily different version!). Next step is to install cpanm and use the latter for installing all the packages you need - for me it works nice and never failed me and it is high-level. Here you may want to keep a list of those packages you installed so that when you migrate you re-install all these modules (there are also ways to get the list of currently installed modules with varied mileages).

The alternative is to have and use only 1 perl: system perl. Just beware that the system can do whatever they want with that perl e.g. upgrading it or its packages. The hosting service should have a snapshot feature somewhere by which you save a working state of the system and if you mess up you just load that snapshot and annul all the rogue changes you did. Whatever you do, using cpanm for installing modules saves a lot of hassle (than using the more low-level cpan command).

BEWARE: with the above or just by logging as root using SSH you can mess up the system and then Christmas will really be cancelled. So: prudence, snapshots, backups.

bw, bliako

The question now is why cPanel does not allow you to install (some?) modules. Without me ever using cPanel or knowing what's going on in the mind of the hosting service I would guess that the answer is "because you can mess your system very easily". You see Perl is used for some of OS maintenance and if you even upgrade system Perl or a module that system Perl relies on to be on a particular version then some things may break.

cPanel prevents me from installing any modules...I used to be able to, but the powers-that-be decided to remove compiler access. I suspect it is partly to push people to upgrade to a less restrictive hosting package as much as for security reasons. cPanel installs the modules in a user directory, not in Perl's directories so it is not an admin concern. Indeed, to use modules that have been installed, this is from cPanel within the hosting:

Your Perl script needs to know how to find the modules in your path. You can do this by adding one of the two choices below to the top of your script:

#!/usr/bin/perl
use cPanelUserConfig;
[download]

or

#!/usr/bin/perlml
[download]

Earlier today I installed local::lib on the suggestions of Corion which worked until I came to . ~/.bashrc which gave a "Permission denied" error. So I am rather restricted on what is possible! But, at least I now have a means of installing Perl modules without the support ticket lottery.

UPDATE:

I need to have use cPanelUserConfig; in place to be able to bring in a module that I have installed using CPAN instead of cPanel. However, that module doesn't appear in the list of installed modules displayed by cPanel.

re: . ~/.bashrc permission denied: it's best to login/logout. But if you insist do this first: chmod 700 ~/.bashrc

So I am rather restricted on what is possible!

No! Don't forget: you (as root) are the most powerful user within the bytes and circuits you rented from them for as long as your credit flows. You can do anything (unless something changed in hosting when I looked away)

Please take advice from other Monks on this one: All these use cPanelUserConfig; and especially #!/usr/bin/perlml seem to me to constrain you. For example, in future migrations to other hostings. Plus, when you ftp your code from home into the site you must then manually edit each and every script to incorporate these special headers. This is not practical (for me). So why don't you just re-install all your modules from commandline, try to replicate your home environment onto the host, and do without these use statements on each and every script/module ? Btw, when you are more confident command-line user can save some money if they charge for cPanel.

Additionally using #!/usr/bin/perlml in a perl script which you execute, tells the shell that the script text which follows that *shebang line* should be interpreted (run through) the command /usr/bin/perlml . Which, I guess, is some perl the host installed to be compatible with cPanel module installations etc. Or, perhaps it's a shell script which sets various ENV vars in order for Perl to load modules from certain paths etc. If you are running a perl-based website you must control 100% the Perl version and the Perl modules. But again, I am not running a commercial website myself (a tiny one anyway which does not count), so please seek advice from other Monks more experienced with this situation.

bw, bliako

unless your disk quota is woefully low

It is "unlimited"...I don't know what that means in real terms but the limit should be sufficient that it makes no practical difference

You can easily take back control of your hosting environment by using perlbrew

I tried that and hit another problem -> Perlbrew on shared hosting