setting CPAN_OPTS environment variable fails

[stuart-little]

I'm running:

${HOME}/perl5/bin/cpan version 1.64 calling Getopt::Std::getopts (version 1.12 [paranoid]),
running under Perl version 5.28.1.

I have been trying to run installs without testing by setting the CPAN_OPTS environment variable as documented, e.g. here (as well as in the cpan manpages on all of my machines). The problem is that the contents of that variable seem to be appended rather than prepended to the rest of my arguments.

The three commands

cpan CPAN -T
CPAN_OPTS="-T" cpan CPAN
export CPAN_OPTS="-T" && cpan CPAN

have exactly the same effect:

Loading internal logger. Log::Log4perl recommended for better logging
Reading '${HOME}/.cpan/Metadata'
  Database was generated on Thu, 02 Jan 2020 14:41:03 GMT
CPAN is up to date (2.27).
>(error): Could not expand [-T]. Check the module name.
>(info): I can suggest names if you install one of Text::Levenshtein::XS, Text::Levenshtein::Damerau::XS, Text::Levenshtein, and Text::Levenshtein::Damerau::PP
>(info): and you provide the -x option on invocation.
>(error): Skipping -T because I couldn't find a matching namespace.

---

In retrospect, it should be easy to see why this would happen. In the cloned git repo:

$ grep -rE '_OPTS' ./

./scripts/cpan:=item CPAN_OPTS
./lib/App/Cpan.pm:=item CPAN_OPTS
./lib/App/Cpan.pm:      push @ARGV, grep $_, split /\s+/, $ENV{CPAN_OPTS} || '';

That last line pushes instead of unshifting. But then how are any of these options supposed to work?

[andk]

>>>> On Thu, 02 Jan 2020 07:53:35 -0800, stuart-little ***@***.***> said:

I'm running: ${HOME}/perl5/bin/cpan version 1.64 calling Getopt::Std::getopts (version 1.12 [paranoid]), running under Perl version 5.28.1. It might be that you have to upgrade, I don't know. 1.675 is current. Upgrading would be done with: $ cpan [...] cpan shell -- CPAN exploration and modules installation (v2.27) [...] cpan[1]> upgrade App::Cpan I have been trying to run installs without testing by setting the CPAN_OPTS environment variable as documented, e.g. here (as well as in the cpan manpages on all of my machines). The problem is that the contents of that variable seem to be appended rather than prepended to the rest of my arguments. The -T option is documented and I can confirm, it indeed seems to work. Note: I have not written the code, so I'm rather trying out what the manpage suggests. See below. The three commands cpan CPAN -T CPAN_OPTS="-T" cpan CPAN export CPAN_OPTS="-T" && cpan CPAN The manpage has these two lines: # with switches, installs modules with extra behavior cpan [-cfFimtTw] module_name [ module_name ... ] So I tried this: cpan -T DateTimeX::Web and it worked as advertized. Can you please do likewise? have exactly the same effect: Loading internal logger. Log::Log4perl recommended for better logging Reading '${HOME}/.cpan/Metadata' Database was generated on Thu, 02 Jan 2020 14:41:03 GMT CPAN is up to date (2.27). > (error): Could not expand [-T]. Check the module name. > (info): I can suggest names if you install one of Text::Levenshtein::XS, Text::Levenshtein::Damerau::XS, Text::Levenshtein, and Text::Levenshtein::Damerau::PP > (info): and you provide the -x option on invocation. > (error): Skipping -T because I couldn't find a matching namespace. It is maybe not worthwhile to understand why these incantations malfunction as you describe. Maybe the manpage needs a sentence or two about the correct incantation. Let me know if you have an idea what could have helped you? Greetings, -- andreas

[stuart-little]

@andk: I understand cpan -T <package> works; it does for me too! The problem is it doesn't work if the -T comes after the package name, and that's exactly what setting CPAN_OPTS="-T" does.

So again: the problem isn't with the -T option, but with the CPAN_OPTS variable, which is appended to the package name instead of being prepended.

I don't think there's much to understand: the problem is, as indicated in my edit to the original message, in the line

push @ARGV, grep $_, split /\s+/, $ENV{CPAN_OPTS} || '';

in lib/App/Cpan.pm: the push means the CPAN_OPTS contents are added to the end of @ARGV, when in fact they should be added to the beginning with an unshift.

[stuart-little]

Actually, that's literally the only change needed to make CPAN_OPTS work as advertised. I simply opened my

${PERL5LIB}/App/Cpan.pm

and changed

push @ARGV, grep $_, split /\s+/, $ENV{CPAN_OPTS} || '';

to

unshift @ARGV, grep $_, split /\s+/, $ENV{CPAN_OPTS} || '';

Now everything works! The command export CPAN_OPTS="-T" && cpan CPAN now adds the -T to the beginning of the @ARGV passed to cpan, and turns off the testing as desired.

---

In short, I would propose the following patch:

--- a/lib/App/Cpan.pm
+++ b/lib/App/Cpan.pm
@@ -410,7 +410,7 @@ sub _process_options
        {
        my %options;
 
-       push @ARGV, grep $_, split /\s+/, $ENV{CPAN_OPTS} || '';
+        unshift @ARGV, grep $_, split /\s+/, $ENV{CPAN_OPTS} || '';
 
        # if no arguments, just drop into the shell
        if( 0 == @ARGV ) { CPAN::shell(); exit 0 }

[andk]

>>>> On Thu, 02 Jan 2020 09:32:40 -0800, stuart-little ***@***.***> said:

@andk: I understand cpan -T <package> works; it does for me too! The problem is it doesn't work if the -T comes after the package name, and that's exactly what setting CPAN_OPTS="-T" does. OK, I'm sorry, that I misunderstood you. Thank you for correcting me. Have you noticed, that there is no test in the t/ directory dealing with CPAN_OPTS: % git grep -i CPAN_OPTS t | wc -l 0 If no usage whatsoever of CPAN_OPTS works at the moment, we could also scratch it, because that would mean that nobody has ever used it. Do you think it has merit? Which would that be? And would you be willing to derive tests for the test suite?

…

-- andreas

[stuart-little]

Have you noticed, that there is no test in the t/ directory dealing with
CPAN_OPTS:

I hadn't noticed that, no.

If no usage whatsoever of CPAN_OPTS works at the moment, we could also
scratch it, because that would mean that nobody has ever used it.

Do you think it has merit? Which would that be? And would you be willing
to derive tests for the test suite?

I have never written a test suite for anything (I only write perl for personal small utility scripts), so I wouldn't know where to begin.

However, given that literally a one-word fix will patch this up and restore the functionality advertised by the man page, wouldn't that be the wiser course of action?

After all, scratching the environment variable completely would require modifying documentation, leaving a number of related but different online sources out of date (e.g. here ), and so on. All of that seems more drastic than simply switching that push to an unshift.