You were exactly right, and while the absense of core modules might be problematic for a Carton, it is immaterial to a cpanfile, which, after a ton of reading about it, seems to suit my needs fine. I have been trying to implement them in varying ways and find success in a bash script that relies on scandeps.pl .

It seems to me that it invites disaster to compose a cpanfile by hand, never mind the tedium. It has to be named 'cpanfile' for the command sudo cpanm --installdeps . to work. There has been a fair amount of evolution in these matters over the years, so newer sources of information are more reliable. I found these html pages helpful and up to date: specifying-dependencies-for-your-cpan-distribution and introduction-to-distribution-metadata. The bash script wraps the invocation of scandeps.pl, creating a directory to house the files to be scanned and the resulting cpanfile. I also get a "paper trail" for what happens on STDOUT with | tee -a "$out" .

Here is sample output:

$ ./1.cpan_dir.sh 
mkdir: cannot create directory ‘logs’: File exists
basename dollar sign zero is 1.cpan_dir.sh
path is /logs
Munged time is 02-03-2020_17-25-09
out fn is /home/hogan/Documents/hogan//logs/02-03-2020_17-25-09.log
/home/hogan/Documents/hogan
/home/hogan/Documents/hogan/cpan_file_dir2
/home/hogan/Documents/hogan/cpan_file_dir2/cpanfile
/home/hogan/Documents/hogan/cpan_file_dir2/scandeps.pl
--> Working on .
Configuring /home/hogan/Documents/hogan/cpan_file_dir2 ... OK
<== Installed dependencies for .. Finishing.
behold your output:
requires "ExtUtils::MM_AIX", "7.44";
requires "ExtUtils::MM_Any", "7.44";
requires "ExtUtils::MM_BeOS", "7.44";
requires "ExtUtils::MM_Cygwin", "7.44";
requires "ExtUtils::MM_DOS", "7.44";
requires "ExtUtils::MM_Darwin", "7.44";
requires "ExtUtils::MM_MacOS", "7.44";
requires "ExtUtils::MM_NW5", "7.44";
requires "ExtUtils::MM_OS2", "7.44";
requires "ExtUtils::MM_QNX", "7.44";
requires "ExtUtils::MM_UWIN", "7.44";
requires "ExtUtils::MM_Unix", "7.44";
requires "ExtUtils::MM_VMS", "7.44";
requires "ExtUtils::MM_VOS", "7.44";
requires "ExtUtils::MM_Win32", "7.44";
requires "ExtUtils::MM_Win95", "7.44";
requires "ExtUtils::MakeMaker", "7.44";
requires "File::Temp", "0.2309";
requires "Module::ScanDeps", "1.27";

duration=20
Mon Feb  3 17:25:29 PST 2020
$
[download]

Source:

#!/bin/bash
#  
# 
#  keep a log named by time stamp
export PATH=:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/
+bin
set -u
app=${0##*/}
mkdir "logs"
pathto=/logs
timename=$(date +"%m-%d-%Y_%H-%M-%S")
out=$HOME/Documents/hogan/$pathto/$timename.log
declare -ir SUCCESS=0
declare -ir E_FATAL=1

if [ 1 -eq 1 ] ; then
echo "basename dollar sign zero is" $app
echo "path is" $pathto
echo "Munged time is" $timename
echo "out fn is $out"
echo "Time is $timename " > "$out"
fi # end if [ 1 -eq 0 ] 

pwd | tee -a "$out"
folder='cpan_file_dir2'
mkdir $folder
cp /home/hogan/.cpan/build/Module-ScanDeps-1.27-0/blib/script/scandeps
+.pl $PWD/$folder/ 
cd $folder
pwd | tee -a "$out"
scandeps.pl -R *.pl | perl -ne   'printf qq{requires "%s", "%s";\n}, e
+val' >>cpanfile
ls -d $PWD/* | tee -a "$out"
sudo cpanm --installdeps . | tee -a "$out"
echo "behold your output:" | tee -a "$out"
cat cpanfile | tee -a "$out"
gedit $out & 
read -n 1
echo "duration=$SECONDS"  | tee -a "$out"
date  | tee -a "$out"
exit $SUCCESS
[download]

So, yay, that I'm getting results, but I don't quite understand the line of code I'm using to get them. Can you "talk through" what happens on this line, in particular, how the %s's get populated?

Thank you for your comments.

So, yay, that I'm getting results, but I don't quite understand the line of code I'm using to get them. Can you "talk through" what happens on this line, in particular, how the %s's get populated?

scandeps.pl -R *.pl | perl -ne 'printf qq{requires "%s", "%s";\n}, eva
+l'
[download]

Sure:

1. The output of scandeps.pl looks something like:

   'Module::Name'  => 'version',
   'Module::Other' => 'version',
   ...
   [download]

2. The output of scandeps.pl is fed into perl, which due to the -n switch reads its input line-by-line, setting $_ to each line.
3. eval evaluates $_ when given no arguments, so it'll evaluate each line, a string such as "'Module::Name' => 'version'", as Perl code.
4. The =>, aka the "fat comma", is just a Comma Operator in disguise, so each line of input evaluates to a list of two values, the module name and its version.
5. Assuming no syntax errors, eval returns these two values, and they are used as the two arguments to the printf.

It seems to me that it invites disaster to compose a cpanfile by hand, never mind the tedium.

Personally, I don't think so - note that the output of scandeps.pl can sometimes be a lot more verbose than it needs to be. I think it's better to get an understanding of what the module dependency tree looks like instead of blindly relying on the tool - I usually try to keep track of which CPAN dependencies I add to my scripts, and I only use scandeps.pl to get hints whether I may have missed something. Note that in the output you showed, all the the ExtUtils::MM_* modules can probably be omitted, and also ExtUtils::MakeMaker and File::Temp are core modules, meaning that unless your script requires a certain new version of them, they usually don't need to be listed.

scandeps.pl -R *.pl | perl -ne   'printf qq{requires "%s", "%s";\n}, e
+val'
[download]

String eval? Eeeeeew :)

scandeps -B -c -C scandep-cache.dat -R *.pl |perl -pe "s{,}{;}; s{=>}{
+,}; s{^}{require }; "
[download]