Perl script to dump the urls submitted by an HN user
gist.github.com
gist.github.com
#!/usr/bin/perl
use strict;
use warnings;
use LWP::Simple;
my %urls = ();
process( "http://news.ycombinator.com/submitted?id=$ARGV[0]" );
print join("\n",sort keys %urls)."\n";
sub process {
my $html = get( $_[0] );
$html =~ s#<td class="title"><a href="(http[^"]+)#$urls{$1}++#eg;
process("http://news.ycombinator.com$1") if $html =~ m#<a href="(/x\?fnid=[^"]+)" rel="nofollow">More</a>#;
} wget -q -O - http://news.ycombinator.com/submitted?id=adulau | grep -o 'title"><a href="[^"]*" rel="nofollow">[^<]*<' | sed -e 's/title"><a href="\([^"]*\)" rel="nofollow">\([^<]*\)</\2 - \1/'I think you'll find if you try this program yourself, you're going to be spending a lot of time downloading and installing CPAN dependencies, few of which can likely be satisfied by your OS's package manager.
Yikes. This would be why I don't share root with anyone who thinks it's a good idea to smuggle stuff onto a box without going through the system package manager (which is rpm or dpkg or the like, not the cpan client or any other single-language ghetto).
- Installing stuff into system directories from through a second package management system (perl = cpan, ruby = gems, etc) is generally a bad idea (e.g. the apt-maintained perl libraries are not seen by cpan, so it will need to install those if there is a requirement for one of them in a cpan package you are installing).
- Upgrading versions of Perl libraries that are used by system (outside of the official package management system) Perl scripts can cause unexpected results.
This is why perlbrew is useful. It manages self-contained Perl installations that you can switch between in your particular environment.
The only downside that I've seen is with system-installed scripts that use the "#!/usr/bin/env perl" method to specify which Perl to run. I haven't seen this, in particular with Perl scripts, but I ran into this with virtualenv + comix as a Python script with "#!/usr/bin/env python" for the shebang line (it blew up since my virtualenv didn't have py-gtk installed).
That's what a lot of languages resort to, but as the proverb goes, now you have two problems. We instead make OS packages out of library dependencies that didn't already have them, so we have a way to legitimately deploy them to production servers.
use strict;
use warnings;
use common::sense;