Makes DateTime much easier to use.
Just what I was looking for: a way of opening a PDF file using whatever the user's standard PDF viewer is.
With Win32::FetchCommand it takes just a single line to interrogate the system to find the correct command to run.
(A star deducted because tests have been failing for a while, and it's necessary to skip testing to get it to install.)
This module doesn't do anything! It's just a wrapper round Perl6::Slurp that doesn't add anything at all: the filename you provide is passed to slurp, and returned.
There's nothing Debian-specific about this module. It doesn't know anything about the location of the packages file (you have to supply that) or its contents or format (you have to parse them).
The entire file gets read into an array. If you're going to be processing the lines one at a time this is probably unnecessary, and read line by line with while(<>) would suffice.
I can't see any situation in which this module is of use.
I wanted to convert an HTML-style hex string into 3 separate integer components. This module provides that, straightforwardly.
Archive::Zip works well, and is easy enough to pick up. I've just written a working program within 10 minutes of installing the module, and that included reading the documentation.
I wanted to run a substitution over a file that happens to be in a zip archive. Archive::Zip made this straightforward, and saved me from having to mess around with temporary files.
I haven't used this module, but it's unclear how what it offers is different from the established CLASS module. If it does have advantages then the doc should mention them (and link to CLASS in its SEE ALSO section).
Paths naturally suit an object-oriented interface, and Path::Class gets that interface just right. All common path operations are supported, and having manipulated things to get the required path there are nifty methods for opening it (for reading or writing, throwing an error automatically) or for slurping it all in at once (with optional chomping).
It's so good that I've standardized on it for absolutely everything relating to paths.
Also, its author has been tremendously responsive in accepting patches and adding in new features when I've suggested ways of making the module even easier to use.
What isn't clear from reading the docs of this new module is why somebody should choose to use it instead of the established Path::Class. I didn't spot any features it offers over Path::Class, and nor have I found Path::Class to be such a resource hog that the need for a lighter alternative is blindingly obvious.
(I haven't given a star rating, since I haven't actually used this module.)
I wanted a calendar, with a month per sheet of paper. This module provided one quickly and easily.
I first looked to buy a suitable calendar, and then tried searching for an OpenOffice template for printing my own, both without success. I was about to resort to writing a program to print my own when I found PostScript::Calendar, which saved the effort The example program which comes with the module was an excellent template, and only required minor tweaking to get the output I wanted.
There are a few caveats (see AnnoCpan), but if you want to create month-per-sheet calendars this module has already done most of the work for you.
Hmmm. This module is first released on August 2nd and less than a week later the UK is on the highest terror alert level. Did the module author have advance notice of the plans? I think we should be told.
This distribution is Cpan spam: it doesn't do anything, and doesn't even claim to do anything other than provide a link to the uploader's websites, sites which has nothing to do with Cpan.
Ironically, I don't even think it'll help those sites in search engine rankings, since their URLs are only provided as plain text not as links. So not only is this an abuse of Cpan and a waste of space, it isn't even doing its uploader (I refrain from using the term "author" for somebody who hasn't written anything) any good.
This module works: it is easy to use it to manipulate a .htpasswd file, adding and deleting entries and changing passwords.
But I am concerned by the author's attitudes to security and to his users. It is good that there is a feature for unconditionally changing a password, and also good that there is one for only changing the password if the previous password is provided. But it was a daft design that conflated these things such that trying to do the latter would always succeed if the user supplied the 'password' "1" -- especially since these 2 features are documented as separate items in the list of functions, so it isn't immediately obvious that they are actually the same function but invoked slightly differently.
In fact the password changing would always succeed if any single digit was given as the previous password. Somebody (not me) usefully added this information on AnnoCpan, and highlighted that programmers should check for this case to avoid a security risk. The module author responded with the ludicrous claim "If the above issue is exploitable, it's because of bad CGI programming, not the module."
He added: "Also, that interface will be changed Real Soon Now anyways" (which seems a touch defensive, and rather undermines his case that the module's interface wasn't a problem). He did indeed fix this problem within a few hours (version 1.70), which is excellent.
Doing so involved making a backwards incompatible interface change. That is inevitable (to distinguish between the 2 conflated features), and I'm glad the change was made, but it's still unfortunate: the security hole is fixed for the 'checking' feature, but all code wanting the 'unconditional' feature (and which could've been working since 1998) is suddenly broken when using the latest version of this module.
The distribution does not follow the convention of listing changes in a separate file, but instead puts them at the end of the main pod. The entry for 1.70 is "Handle SHA1 and plaintext. Also change the interface for allowing change of password without first checking old password. IF YOU DON'T READ THE DOCS AND SEE I DID THIS DON'T EMAIL ME!"
Note the lack of reason for the change, the lack of note warning that using previous versions has a security risk, the lack of apology for the change (or for the vulnerability, for that matter) -- and the implication that the module author is free to change any interface at any time and that if this breaks things its the module users' fault; without the context for this change it looks like it was just made on the author's whim.
We're continuing using this module (it does work!), but making sure we watch it more closely than we do with most Cpan modules.
This is in response to Lee's comment on the name of this module: This is an entirely appropriate use of the WebService:: namespace, which is for modules that provide Perl interfaces to services available on particular websites. This namespace has been championed by email@example.com for this purpose, in the hope of distinguishing such modules from general-purpose WWW-related modules (not related to any particular website, such as WWW::Mechanize) which populate the WWW:: namespace.
(And a module related to Soap would probably be found in the SOAP:: interface.)
Like the standard FindBin module, but works under mod_perl and other persistent environments -- the directory is calculated each time in a function call, rather than cached in a global variable. This makes the interface slightly less convenient, and presumably makes it slower as well.
The "Real" suffix on the name is a little misleading: both FindBin and FindBin::Real provide both Bin and RealBin directories (the latter being with links resolved).
Oy, Nightcat: Giving a 5-star review to your own module (and not including any content backing that up) is not on. Especially without even stating that you're the module's author.
A simple module which neatly overcomes a glitch in Perl by providing a simple interface for loading modules chosen dynamically at run time.
Does it exactly what it claims: causes 'Apache' to automatically reload Perl modules when they have been changed.
This module is redundant: it tries to solve problems that are already solved by MIME::Base64, but using this module over MIME::Base64 has no advantages yet does have the disadvantages of the encoded format being its own rather than a standard one, so there is no chance of interoperability with anything other than another script using this module, and it would be unfamiliar and confusing to anybody already used to achieving this in standard ways.
Further, everybody already has the MIME::Base64 module (comes as standard with Perl) whereas this one would need installing for use. It also demands Perl 5.8.1 to run (though seems to run with earlier versions if that line is removed).
Finally the module name is badly capitalized ("Text::Toalpha" should be "Text::ToAlpha", to make it easy to see the word boundaries), though it doesn't seem a particularly descriptive name anyway.
Net::Telnet is great for quickly writing Perl which automates a human using the telnet command in a predictable way, for example tweaking the config on network switches which provide a telnet interface. I know it's wrong, but often abusing a human-oriented telnet interface like this is less hassle than dealing with the supposedly computer-oriented SNMP interface.
The docs are comprehensive -- a little _too_ comprehensive for my liking: the module is easy to use, but there's a lot of docs to wade through before this becomes apparent. A proper attempt at a 'Synopsis' would help considerably with this.
The logging facility is excellent, allowing you to easily monitor exactly what's going on in an automated telnet session without cluttering up the code with lots of debugging statements.
However having to use class methods, rather than exported functions, is very tedious, _viz_:
Object-orientation makes no sense at all here: there isn't an object in sight.
The ->script_wrap method possibly doesn't belong in this module (and I have a minor quibble with its including the deprecated lang attribute) but it isn't really causing any harm.
It would be much easier to quickly learn what this module achieves if its documentation provided some sample output.
This module works: after a tieing a hash, you get elements back in the order they were inserted. Tie::InsertOrderHash has a slightly nicer interface, where the contents of a hash can be assigned in the tie statement.
The documentation would be much better if it explained what this module does on its own terms, rather than describing itself relative to Tie::IxHash, which the reader may not be familiar with.
I'm not convinced about the name: to me "indexed" makes me think more of being able to access hash elements by number; I'd simply describe a hash of the type this module provides as being "ordered".
I've only used it a little, but this module seems to do exactly what is required if you require a hash to keep its order.
This module requires Perl 5.6.1; in a project that has to run on 5.005 I've used Tie::Hash::Indexed instead, but the interface this module has for assigning data while tieing is nicer.
My only reason for not giving it 5 stars is cos I'm not keen on the name. Putting it in the Tie::Hash::* namespace would have been preferable. Also many modules have a verb as the second part of their name, so when I first saw "Tie::InsertOrderHash" my thought was that it would insert something; I didn't immediately grasp that "InsertOrder" is a truncation of "insertion order". So I think Tie::Hash::InsertionOrder or just Tie::Hash::Ordered would be a better name.
perl5lib solves the problem of wanting to have CGI scripts run in taint
mode but use library modules specified (in the web-server configuration)
in PERL5LIB. If you're in that situation, then this pragma is what you