« Finally: new website design | Main | September 11, 2005 »

September 08, 2005


Jeremy Zawodny

Ah ha!

I've run into this countless times and couldn't figure out WTF CPAN was smoking.



Heh heh, CPAN be teh suck sometimes.


Wow! Thank you for this information. I can't believe how annoying this has been! You're right. Either "install" needs to be ignored by cpan or install doesn't need to be used as the name of a module on CPAN. *sigh*

brian d foy

None of the CPAN.pm shell commands are options for the cpan(1) tool. I could add "install" as a special word, but that doesn't clear up Least Antonishment, since none of the other valid commands from CPAN.pm will work from cpan(1). A tool that specially handles "install" needs a completely different interface to be consistent. To handle that, most of the code in cpan(1) has to be changed since argument processing becomes a lot more complicated for the arguments without leading dashes (and for long arguments).

In general, when a tool is doing something you don't think it should do, try reading its documentation. :)


I've had this same problem for a while, and in fact I've only just now become aware that 'install' didn't do what I thought it did; all I ever do with cpan(1) is install modules or start the CPAN shell, and I never looked any more deeply at it than that.

So now what I want to know is: where did I (and apparently a decent number of other people) get the idea that 'cpan install HTML::Foo' is the correct syntax?


I just figured this out on my own; found this post after googling "cpan junoscript" to make sure I was correct in assuming that "install" is a package name.

I think the assumption that 'cpan install HTML::Foo' is correct comes from the fact that other install programs (PEAR, maybe?) does it that way. Or at least warns you that that's not the valid syntax.

The comments to this entry are closed.


  • Steve Friedl is a software and network security consultant in Southern California. He has been a C and UNIX developer since 1981 and has an exceptionally broad background in this area. Some areas of expertise include:

    • C and C++ systems software development on the UNIX and Win32 platforms
    • Communications, including serial and TCP/IP based controllers
    • Enterprise internet security administration and configuration
    • Penetration tests, audits, and network reviews
    • Security forensics, reverse engineering, and tools development
    • General UNIX and Windows system/network administration
    • The Windows Printing System
    • Database software development
    • Technology problem solving and research
    • Technical writing and standup training

Unix Wiz

Stephen J. FriedlSoftware ConsultantOrange County, CA USASteve@unixwiz.net