How do I restore default perl in macOS Mojave?How to install CPAN modules from the command line on OS X?How to install modules from CPAN without sudo?Problem installing Devel::REPL using cpanmEl Capitan SIP and CPANmacOS Mojave Installation ErrorTrying to downgrade to High Sierra but Time Machine restore upgrades back to MojaveDamaged macOS Mojave installerBrowsers don't restore tabs after quitting in macOS MojaveMacOS Mojave: How do I change the default /Users directory for ALL users logging in?How to install default/stock Terminal app?
How to know the path of a particular software?
Is it standard for US-based universities to consider the ethnicity of an applicant during PhD admissions?
Is there any deeper thematic meaning to the white horse that Arya finds in The Bells (S08E05)?
Would a "ring language" be possible?
Why doesn't Iron Man's action affect this person in Endgame?
Have there been any examples of re-usable rockets in the past?
I recently started my machine learning PhD and I have absolutely no idea what I'm doing
Omit property variable when using object destructuring
Why do galaxies collide?
How to deal with the extreme reverberation in big cathedrals when playing the pipe organs?
Why is vowel phonology represented in a trapezoid instead of a square?
Holding rent money for my friend which amounts to over $10k?
Is Precocious Apprentice enough for Mystic Theurge?
Cycling to work - 30mile return
How does this piece of code determine array size without using sizeof( )?
Pedaling at different gear ratios on flat terrain: what's the point?
Why are there five extra turns in tournament Magic?
Can a person still be an Orthodox Jew and believe that the Torah contains narratives that are not scientifically correct?
How come Arya Stark didn't burn in Game of Thrones Season 8 Episode 5
What kind of action are dodge and disengage?
Do we see some Unsullied doing this in S08E05?
How can we delete item permanently without storing in Recycle Bin?
Why does string strummed with finger sound different from the one strummed with pick?
Canadian citizen who is presently in litigation with a US-based company
How do I restore default perl in macOS Mojave?
How to install CPAN modules from the command line on OS X?How to install modules from CPAN without sudo?Problem installing Devel::REPL using cpanmEl Capitan SIP and CPANmacOS Mojave Installation ErrorTrying to downgrade to High Sierra but Time Machine restore upgrades back to MojaveDamaged macOS Mojave installerBrowsers don't restore tabs after quitting in macOS MojaveMacOS Mojave: How do I change the default /Users directory for ALL users logging in?How to install default/stock Terminal app?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
Is there a way to restore default perl5 and cpan modules in Mojave without rebuilding the OS?
mojave perl
add a comment |
Is there a way to restore default perl5 and cpan modules in Mojave without rebuilding the OS?
mojave perl
1
What happened to them?
– JBis
May 5 at 2:33
Thanks for asking. I was concerned about trashing the OS default perl and cpan after a round of trying to use MacPorts's perl5. I could not get a Github perl project to build (make) with Macports, so I switched to the default perl and the make succeeded. I was then afraid that the process might have mucked up default modules. Can you tell I am a perl noob? Anyway, after much perl -V and file diffs between a clean system and mine, I convinced myself it was fine.
– whitey
May 6 at 16:22
add a comment |
Is there a way to restore default perl5 and cpan modules in Mojave without rebuilding the OS?
mojave perl
Is there a way to restore default perl5 and cpan modules in Mojave without rebuilding the OS?
mojave perl
mojave perl
asked May 5 at 1:07
whiteywhitey
113
113
1
What happened to them?
– JBis
May 5 at 2:33
Thanks for asking. I was concerned about trashing the OS default perl and cpan after a round of trying to use MacPorts's perl5. I could not get a Github perl project to build (make) with Macports, so I switched to the default perl and the make succeeded. I was then afraid that the process might have mucked up default modules. Can you tell I am a perl noob? Anyway, after much perl -V and file diffs between a clean system and mine, I convinced myself it was fine.
– whitey
May 6 at 16:22
add a comment |
1
What happened to them?
– JBis
May 5 at 2:33
Thanks for asking. I was concerned about trashing the OS default perl and cpan after a round of trying to use MacPorts's perl5. I could not get a Github perl project to build (make) with Macports, so I switched to the default perl and the make succeeded. I was then afraid that the process might have mucked up default modules. Can you tell I am a perl noob? Anyway, after much perl -V and file diffs between a clean system and mine, I convinced myself it was fine.
– whitey
May 6 at 16:22
1
1
What happened to them?
– JBis
May 5 at 2:33
What happened to them?
– JBis
May 5 at 2:33
Thanks for asking. I was concerned about trashing the OS default perl and cpan after a round of trying to use MacPorts's perl5. I could not get a Github perl project to build (make) with Macports, so I switched to the default perl and the make succeeded. I was then afraid that the process might have mucked up default modules. Can you tell I am a perl noob? Anyway, after much perl -V and file diffs between a clean system and mine, I convinced myself it was fine.
– whitey
May 6 at 16:22
Thanks for asking. I was concerned about trashing the OS default perl and cpan after a round of trying to use MacPorts's perl5. I could not get a Github perl project to build (make) with Macports, so I switched to the default perl and the make succeeded. I was then afraid that the process might have mucked up default modules. Can you tell I am a perl noob? Anyway, after much perl -V and file diffs between a clean system and mine, I convinced myself it was fine.
– whitey
May 6 at 16:22
add a comment |
2 Answers
2
active
oldest
votes
Standard binaries are protected by SIP and can‘t easily be removed nor replaced. Booting into recovery and reinstalling macOS only is the easiest way to solve this. You may need to manually reinstall any user-installed CPAN modules again afterwards.
Thanks nohillside. I spaced out on SIP protections. I was concerned after reading many warnings about NOT using Apple's default perl for development. Anyway see my comment to @JBis also.
– whitey
May 6 at 16:26
add a comment |
Good post.
Your native Perl will sit in /usr/bin/perl
.
If you open the terminal app and at the command line prompt type,
/usr/bin/perl -v
If you have not overridden your native Perl the terminal response should be,
This is perl 5, version 18, subversion 2 built for darwin-thread...
The OSX 10.14 might have upgraded from 5.18.2, even so darwin-thread means it is OSX version. In this case reinstallation is not needed because native Perl was not overridden. The symbolic link determining which perl you are using may need modifying.
Core CPAN is here
ls /System/Library/Perl/5.18
or whatever version of perl OSX 10.14 is running just substitute 5.18 with the output of perl -v if they are different.
cpan binary also exists in the same location as perl.
/usr/bin/cpan -v
However, it is clear when I did this /usr/bin binaries can be overridden (the other responder believed this could not happen) because mine complains cpan it is 5.26 (I use ActivePerl 5.26), that explains alot because there is cpan5.18.2
in the same directory. It would appear cpan has been overridden by ActivePerl, bad people and this should not happen but clearly does.
Problem I run my Perl via /usr/local/bin
and simply switch the link from 5.18.2 to ActivePerl (which is not ideal) . I run cpan via cpanm (Anaconda) and ppm (Active perl), so cpan is never used.
Solution for me I need to change my setup for running Perl, like you, not by reinstallation but by restoring the old link in /usr/local/bin from ActivePerl and running it from my own local bin and also redirect the cpan
to cpan5.18 in /usr/local/bin (although this might affect ActivePerl's ppm command). Add a comment if you want to know how to do this
The recommended method for future reference for avoiding damaging system Perl is to install Perlbrew or plvar, this keeps everything clean. Again comment below for tips
Possible solution If your core Perl is dead beyond repair ActivePerl might recover this (its a big might), and configure via /usr/local/bin like I should not have done. Anyway its easy enough to try and there is a clean uninstall with it. Again please drop a note in comments if you want advice
I'm not sure I fully understand what your answer here is. Can you edit your answer and focus on the actual steps the OP could take to fix theirperl
setup?
– nohillside♦
May 5 at 8:18
Done, I can't give complete advice without the output of report logs indicated here. The OP must know what CPAN is, so no explanation is required. There are other ways to solve this without reinstalling the entire OS, beyond what I've said here
– Michael G.
May 5 at 9:21
I miss the specific steps the OP should take. If you don‘t know enough about the specific problem yet putting a comment beneath the question might help
– nohillside♦
May 5 at 9:44
The terminal commands to generate the outputs are clear. The OP is a perl programmer, they must be because they understand cpan. It is better for the OP to decide . My guess is the user has installed a new version of Perl and this has disrupted the symbolic links to their native Perl (perl programmers always do this because OSX is behind the current release). If you don't understand Perl it will not be easy to follow the trouble shooting. Alternatively the OP may have trashed native Perl, which is difficult but doable, but we don't know until the output logs of the commnds above are released.
– Michael G.
May 5 at 10:23
1
Thanks for the suggestions. I followed some of these in my steps in my research as well. I eventually satisfied myself that all was well.
– whitey
May 6 at 16:42
|
show 1 more comment
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Standard binaries are protected by SIP and can‘t easily be removed nor replaced. Booting into recovery and reinstalling macOS only is the easiest way to solve this. You may need to manually reinstall any user-installed CPAN modules again afterwards.
Thanks nohillside. I spaced out on SIP protections. I was concerned after reading many warnings about NOT using Apple's default perl for development. Anyway see my comment to @JBis also.
– whitey
May 6 at 16:26
add a comment |
Standard binaries are protected by SIP and can‘t easily be removed nor replaced. Booting into recovery and reinstalling macOS only is the easiest way to solve this. You may need to manually reinstall any user-installed CPAN modules again afterwards.
Thanks nohillside. I spaced out on SIP protections. I was concerned after reading many warnings about NOT using Apple's default perl for development. Anyway see my comment to @JBis also.
– whitey
May 6 at 16:26
add a comment |
Standard binaries are protected by SIP and can‘t easily be removed nor replaced. Booting into recovery and reinstalling macOS only is the easiest way to solve this. You may need to manually reinstall any user-installed CPAN modules again afterwards.
Standard binaries are protected by SIP and can‘t easily be removed nor replaced. Booting into recovery and reinstalling macOS only is the easiest way to solve this. You may need to manually reinstall any user-installed CPAN modules again afterwards.
edited May 5 at 6:22
answered May 5 at 5:58
nohillside♦nohillside
54.1k14113160
54.1k14113160
Thanks nohillside. I spaced out on SIP protections. I was concerned after reading many warnings about NOT using Apple's default perl for development. Anyway see my comment to @JBis also.
– whitey
May 6 at 16:26
add a comment |
Thanks nohillside. I spaced out on SIP protections. I was concerned after reading many warnings about NOT using Apple's default perl for development. Anyway see my comment to @JBis also.
– whitey
May 6 at 16:26
Thanks nohillside. I spaced out on SIP protections. I was concerned after reading many warnings about NOT using Apple's default perl for development. Anyway see my comment to @JBis also.
– whitey
May 6 at 16:26
Thanks nohillside. I spaced out on SIP protections. I was concerned after reading many warnings about NOT using Apple's default perl for development. Anyway see my comment to @JBis also.
– whitey
May 6 at 16:26
add a comment |
Good post.
Your native Perl will sit in /usr/bin/perl
.
If you open the terminal app and at the command line prompt type,
/usr/bin/perl -v
If you have not overridden your native Perl the terminal response should be,
This is perl 5, version 18, subversion 2 built for darwin-thread...
The OSX 10.14 might have upgraded from 5.18.2, even so darwin-thread means it is OSX version. In this case reinstallation is not needed because native Perl was not overridden. The symbolic link determining which perl you are using may need modifying.
Core CPAN is here
ls /System/Library/Perl/5.18
or whatever version of perl OSX 10.14 is running just substitute 5.18 with the output of perl -v if they are different.
cpan binary also exists in the same location as perl.
/usr/bin/cpan -v
However, it is clear when I did this /usr/bin binaries can be overridden (the other responder believed this could not happen) because mine complains cpan it is 5.26 (I use ActivePerl 5.26), that explains alot because there is cpan5.18.2
in the same directory. It would appear cpan has been overridden by ActivePerl, bad people and this should not happen but clearly does.
Problem I run my Perl via /usr/local/bin
and simply switch the link from 5.18.2 to ActivePerl (which is not ideal) . I run cpan via cpanm (Anaconda) and ppm (Active perl), so cpan is never used.
Solution for me I need to change my setup for running Perl, like you, not by reinstallation but by restoring the old link in /usr/local/bin from ActivePerl and running it from my own local bin and also redirect the cpan
to cpan5.18 in /usr/local/bin (although this might affect ActivePerl's ppm command). Add a comment if you want to know how to do this
The recommended method for future reference for avoiding damaging system Perl is to install Perlbrew or plvar, this keeps everything clean. Again comment below for tips
Possible solution If your core Perl is dead beyond repair ActivePerl might recover this (its a big might), and configure via /usr/local/bin like I should not have done. Anyway its easy enough to try and there is a clean uninstall with it. Again please drop a note in comments if you want advice
I'm not sure I fully understand what your answer here is. Can you edit your answer and focus on the actual steps the OP could take to fix theirperl
setup?
– nohillside♦
May 5 at 8:18
Done, I can't give complete advice without the output of report logs indicated here. The OP must know what CPAN is, so no explanation is required. There are other ways to solve this without reinstalling the entire OS, beyond what I've said here
– Michael G.
May 5 at 9:21
I miss the specific steps the OP should take. If you don‘t know enough about the specific problem yet putting a comment beneath the question might help
– nohillside♦
May 5 at 9:44
The terminal commands to generate the outputs are clear. The OP is a perl programmer, they must be because they understand cpan. It is better for the OP to decide . My guess is the user has installed a new version of Perl and this has disrupted the symbolic links to their native Perl (perl programmers always do this because OSX is behind the current release). If you don't understand Perl it will not be easy to follow the trouble shooting. Alternatively the OP may have trashed native Perl, which is difficult but doable, but we don't know until the output logs of the commnds above are released.
– Michael G.
May 5 at 10:23
1
Thanks for the suggestions. I followed some of these in my steps in my research as well. I eventually satisfied myself that all was well.
– whitey
May 6 at 16:42
|
show 1 more comment
Good post.
Your native Perl will sit in /usr/bin/perl
.
If you open the terminal app and at the command line prompt type,
/usr/bin/perl -v
If you have not overridden your native Perl the terminal response should be,
This is perl 5, version 18, subversion 2 built for darwin-thread...
The OSX 10.14 might have upgraded from 5.18.2, even so darwin-thread means it is OSX version. In this case reinstallation is not needed because native Perl was not overridden. The symbolic link determining which perl you are using may need modifying.
Core CPAN is here
ls /System/Library/Perl/5.18
or whatever version of perl OSX 10.14 is running just substitute 5.18 with the output of perl -v if they are different.
cpan binary also exists in the same location as perl.
/usr/bin/cpan -v
However, it is clear when I did this /usr/bin binaries can be overridden (the other responder believed this could not happen) because mine complains cpan it is 5.26 (I use ActivePerl 5.26), that explains alot because there is cpan5.18.2
in the same directory. It would appear cpan has been overridden by ActivePerl, bad people and this should not happen but clearly does.
Problem I run my Perl via /usr/local/bin
and simply switch the link from 5.18.2 to ActivePerl (which is not ideal) . I run cpan via cpanm (Anaconda) and ppm (Active perl), so cpan is never used.
Solution for me I need to change my setup for running Perl, like you, not by reinstallation but by restoring the old link in /usr/local/bin from ActivePerl and running it from my own local bin and also redirect the cpan
to cpan5.18 in /usr/local/bin (although this might affect ActivePerl's ppm command). Add a comment if you want to know how to do this
The recommended method for future reference for avoiding damaging system Perl is to install Perlbrew or plvar, this keeps everything clean. Again comment below for tips
Possible solution If your core Perl is dead beyond repair ActivePerl might recover this (its a big might), and configure via /usr/local/bin like I should not have done. Anyway its easy enough to try and there is a clean uninstall with it. Again please drop a note in comments if you want advice
I'm not sure I fully understand what your answer here is. Can you edit your answer and focus on the actual steps the OP could take to fix theirperl
setup?
– nohillside♦
May 5 at 8:18
Done, I can't give complete advice without the output of report logs indicated here. The OP must know what CPAN is, so no explanation is required. There are other ways to solve this without reinstalling the entire OS, beyond what I've said here
– Michael G.
May 5 at 9:21
I miss the specific steps the OP should take. If you don‘t know enough about the specific problem yet putting a comment beneath the question might help
– nohillside♦
May 5 at 9:44
The terminal commands to generate the outputs are clear. The OP is a perl programmer, they must be because they understand cpan. It is better for the OP to decide . My guess is the user has installed a new version of Perl and this has disrupted the symbolic links to their native Perl (perl programmers always do this because OSX is behind the current release). If you don't understand Perl it will not be easy to follow the trouble shooting. Alternatively the OP may have trashed native Perl, which is difficult but doable, but we don't know until the output logs of the commnds above are released.
– Michael G.
May 5 at 10:23
1
Thanks for the suggestions. I followed some of these in my steps in my research as well. I eventually satisfied myself that all was well.
– whitey
May 6 at 16:42
|
show 1 more comment
Good post.
Your native Perl will sit in /usr/bin/perl
.
If you open the terminal app and at the command line prompt type,
/usr/bin/perl -v
If you have not overridden your native Perl the terminal response should be,
This is perl 5, version 18, subversion 2 built for darwin-thread...
The OSX 10.14 might have upgraded from 5.18.2, even so darwin-thread means it is OSX version. In this case reinstallation is not needed because native Perl was not overridden. The symbolic link determining which perl you are using may need modifying.
Core CPAN is here
ls /System/Library/Perl/5.18
or whatever version of perl OSX 10.14 is running just substitute 5.18 with the output of perl -v if they are different.
cpan binary also exists in the same location as perl.
/usr/bin/cpan -v
However, it is clear when I did this /usr/bin binaries can be overridden (the other responder believed this could not happen) because mine complains cpan it is 5.26 (I use ActivePerl 5.26), that explains alot because there is cpan5.18.2
in the same directory. It would appear cpan has been overridden by ActivePerl, bad people and this should not happen but clearly does.
Problem I run my Perl via /usr/local/bin
and simply switch the link from 5.18.2 to ActivePerl (which is not ideal) . I run cpan via cpanm (Anaconda) and ppm (Active perl), so cpan is never used.
Solution for me I need to change my setup for running Perl, like you, not by reinstallation but by restoring the old link in /usr/local/bin from ActivePerl and running it from my own local bin and also redirect the cpan
to cpan5.18 in /usr/local/bin (although this might affect ActivePerl's ppm command). Add a comment if you want to know how to do this
The recommended method for future reference for avoiding damaging system Perl is to install Perlbrew or plvar, this keeps everything clean. Again comment below for tips
Possible solution If your core Perl is dead beyond repair ActivePerl might recover this (its a big might), and configure via /usr/local/bin like I should not have done. Anyway its easy enough to try and there is a clean uninstall with it. Again please drop a note in comments if you want advice
Good post.
Your native Perl will sit in /usr/bin/perl
.
If you open the terminal app and at the command line prompt type,
/usr/bin/perl -v
If you have not overridden your native Perl the terminal response should be,
This is perl 5, version 18, subversion 2 built for darwin-thread...
The OSX 10.14 might have upgraded from 5.18.2, even so darwin-thread means it is OSX version. In this case reinstallation is not needed because native Perl was not overridden. The symbolic link determining which perl you are using may need modifying.
Core CPAN is here
ls /System/Library/Perl/5.18
or whatever version of perl OSX 10.14 is running just substitute 5.18 with the output of perl -v if they are different.
cpan binary also exists in the same location as perl.
/usr/bin/cpan -v
However, it is clear when I did this /usr/bin binaries can be overridden (the other responder believed this could not happen) because mine complains cpan it is 5.26 (I use ActivePerl 5.26), that explains alot because there is cpan5.18.2
in the same directory. It would appear cpan has been overridden by ActivePerl, bad people and this should not happen but clearly does.
Problem I run my Perl via /usr/local/bin
and simply switch the link from 5.18.2 to ActivePerl (which is not ideal) . I run cpan via cpanm (Anaconda) and ppm (Active perl), so cpan is never used.
Solution for me I need to change my setup for running Perl, like you, not by reinstallation but by restoring the old link in /usr/local/bin from ActivePerl and running it from my own local bin and also redirect the cpan
to cpan5.18 in /usr/local/bin (although this might affect ActivePerl's ppm command). Add a comment if you want to know how to do this
The recommended method for future reference for avoiding damaging system Perl is to install Perlbrew or plvar, this keeps everything clean. Again comment below for tips
Possible solution If your core Perl is dead beyond repair ActivePerl might recover this (its a big might), and configure via /usr/local/bin like I should not have done. Anyway its easy enough to try and there is a clean uninstall with it. Again please drop a note in comments if you want advice
edited May 5 at 9:20
answered May 5 at 6:50
Michael G.Michael G.
1097
1097
I'm not sure I fully understand what your answer here is. Can you edit your answer and focus on the actual steps the OP could take to fix theirperl
setup?
– nohillside♦
May 5 at 8:18
Done, I can't give complete advice without the output of report logs indicated here. The OP must know what CPAN is, so no explanation is required. There are other ways to solve this without reinstalling the entire OS, beyond what I've said here
– Michael G.
May 5 at 9:21
I miss the specific steps the OP should take. If you don‘t know enough about the specific problem yet putting a comment beneath the question might help
– nohillside♦
May 5 at 9:44
The terminal commands to generate the outputs are clear. The OP is a perl programmer, they must be because they understand cpan. It is better for the OP to decide . My guess is the user has installed a new version of Perl and this has disrupted the symbolic links to their native Perl (perl programmers always do this because OSX is behind the current release). If you don't understand Perl it will not be easy to follow the trouble shooting. Alternatively the OP may have trashed native Perl, which is difficult but doable, but we don't know until the output logs of the commnds above are released.
– Michael G.
May 5 at 10:23
1
Thanks for the suggestions. I followed some of these in my steps in my research as well. I eventually satisfied myself that all was well.
– whitey
May 6 at 16:42
|
show 1 more comment
I'm not sure I fully understand what your answer here is. Can you edit your answer and focus on the actual steps the OP could take to fix theirperl
setup?
– nohillside♦
May 5 at 8:18
Done, I can't give complete advice without the output of report logs indicated here. The OP must know what CPAN is, so no explanation is required. There are other ways to solve this without reinstalling the entire OS, beyond what I've said here
– Michael G.
May 5 at 9:21
I miss the specific steps the OP should take. If you don‘t know enough about the specific problem yet putting a comment beneath the question might help
– nohillside♦
May 5 at 9:44
The terminal commands to generate the outputs are clear. The OP is a perl programmer, they must be because they understand cpan. It is better for the OP to decide . My guess is the user has installed a new version of Perl and this has disrupted the symbolic links to their native Perl (perl programmers always do this because OSX is behind the current release). If you don't understand Perl it will not be easy to follow the trouble shooting. Alternatively the OP may have trashed native Perl, which is difficult but doable, but we don't know until the output logs of the commnds above are released.
– Michael G.
May 5 at 10:23
1
Thanks for the suggestions. I followed some of these in my steps in my research as well. I eventually satisfied myself that all was well.
– whitey
May 6 at 16:42
I'm not sure I fully understand what your answer here is. Can you edit your answer and focus on the actual steps the OP could take to fix their
perl
setup?– nohillside♦
May 5 at 8:18
I'm not sure I fully understand what your answer here is. Can you edit your answer and focus on the actual steps the OP could take to fix their
perl
setup?– nohillside♦
May 5 at 8:18
Done, I can't give complete advice without the output of report logs indicated here. The OP must know what CPAN is, so no explanation is required. There are other ways to solve this without reinstalling the entire OS, beyond what I've said here
– Michael G.
May 5 at 9:21
Done, I can't give complete advice without the output of report logs indicated here. The OP must know what CPAN is, so no explanation is required. There are other ways to solve this without reinstalling the entire OS, beyond what I've said here
– Michael G.
May 5 at 9:21
I miss the specific steps the OP should take. If you don‘t know enough about the specific problem yet putting a comment beneath the question might help
– nohillside♦
May 5 at 9:44
I miss the specific steps the OP should take. If you don‘t know enough about the specific problem yet putting a comment beneath the question might help
– nohillside♦
May 5 at 9:44
The terminal commands to generate the outputs are clear. The OP is a perl programmer, they must be because they understand cpan. It is better for the OP to decide . My guess is the user has installed a new version of Perl and this has disrupted the symbolic links to their native Perl (perl programmers always do this because OSX is behind the current release). If you don't understand Perl it will not be easy to follow the trouble shooting. Alternatively the OP may have trashed native Perl, which is difficult but doable, but we don't know until the output logs of the commnds above are released.
– Michael G.
May 5 at 10:23
The terminal commands to generate the outputs are clear. The OP is a perl programmer, they must be because they understand cpan. It is better for the OP to decide . My guess is the user has installed a new version of Perl and this has disrupted the symbolic links to their native Perl (perl programmers always do this because OSX is behind the current release). If you don't understand Perl it will not be easy to follow the trouble shooting. Alternatively the OP may have trashed native Perl, which is difficult but doable, but we don't know until the output logs of the commnds above are released.
– Michael G.
May 5 at 10:23
1
1
Thanks for the suggestions. I followed some of these in my steps in my research as well. I eventually satisfied myself that all was well.
– whitey
May 6 at 16:42
Thanks for the suggestions. I followed some of these in my steps in my research as well. I eventually satisfied myself that all was well.
– whitey
May 6 at 16:42
|
show 1 more comment
1
What happened to them?
– JBis
May 5 at 2:33
Thanks for asking. I was concerned about trashing the OS default perl and cpan after a round of trying to use MacPorts's perl5. I could not get a Github perl project to build (make) with Macports, so I switched to the default perl and the make succeeded. I was then afraid that the process might have mucked up default modules. Can you tell I am a perl noob? Anyway, after much perl -V and file diffs between a clean system and mine, I convinced myself it was fine.
– whitey
May 6 at 16:22