Installing dependencies is pain.
I just did this on a freshly-installed perl 5.34.0. What did you try?
$ cpan Regexp::Log::Common DateTime::Format::HTTP Number::Format
It took a while, but I’m on a slow VPS.
This went faster and made less noise:
$ cpan App::cpanminus
$ cpanm Regexp::Log::Common DateTime::Format::HTTP Number::Format
I’ve taken to doing a thing for publicly-available Perl utilities in which
This lets people use the thing without installing any deps, but also provides a low barrier to entry to people who want to contribute (they don’t need to use all of my dev tooling, don’t need to use Carton, and don’t even need to find their own decent CPAN client).
I’ve been meaning to make the script from #3 into something generalized and redistributable, but… not enough time.
The point of the post was to describe the code for edification, not to distribute it as an installable package.
Sure, that’s fine. Sorry, just sharing, not trying to push you into doing anything :)
It was a general complain. I see that people are rediscovering awk and I thought that perl could be the next thing they will use. But after seeing your example it occurred to me that will likely not happen because of tooling. In awk you write a simple, fire and forget script. If you decide you want to write the same script in perl you would use some modules. But on order to do so you need to run your code to see what’s missing. Then install cpanm (you need to know that it exists and why you want to use it) with cpan. Then manually enter required modules name, go for a walk and hope for the best. I know there are/were projects like carton, perl brew, cpanfile but what I want is to be able to write my code and just run it without all the effort needed to set up my environment. It makes writing scripts in perl too much work and there are better languages to write my apps with.
Perl is a superset of awk: see a2p(1p) (a core Perl script).
You don’t need to use external modules to use Perl scripts. The core has a bunch. OP elected to use a module for web log parsing because it was available, not because it was the only way.
All succesful languages rely on modules and libraries. Distributing these is an age-old problem. Perl has one solution, which may seem old fashioned, but at least for me, it’s way easier to understand that Python’s (or containers, for that matter).
Edit in my experience, a lot of *nix software managers include the most popular Perl modules as native “units”. Off the top of my head, this includes Debian/Ubuntu and Free- and OpenBSD.
I like Perl too. (As an aside, I recommend not using GitHub to host code blocks. They render in a huge font size on iPhone and are broken in reader mode.)
Thanks for the feedback! I’ve replaced them with regular code blocks.
awk is great but I find I can do pretty much all of its record-at-a-time parsing with perl’s -n or -p switches, and the latter’s autosplit -a switch saves a lot of time. The other record- and field-parsing switches documented in perlrun also get a lot of play. Plus if you’re needing to bring in other features like database connections or output in formats like JSON, XML, or YAML you can tap into modules from CPAN.
awk will always win at raw speed for what it does, but it’s another slightly-less-appropriate-to-general-programming tool to learn and master. As soon as your pipeline gets a bit too complicated to comfortably implement in shell and awk you’ll be reaching for Perl anyway – that was its original use case, after all.
One big difference is that in 2021, searching for Awk documentation and tutorials will give you information about record-at-a-time text processing, while searching for Perl documentation and tutorials digs up information about writing CGI scripts and maintaining legacy codebases. As somebody who occasionally wants to write portable text-processing tools, I’m pretty sure Perl would be a better choice than awk most of the time, but since I didn’t learn Perl before 1995 I feel like that knowledge has been lost.
Thank you for the excellent blog post idea!
Follow-up blog post here
Agreed. I use Ruby, though. Ruby has much better syntax and has inherited -n & -p goodness from Perl.
Attending Dragon Con in Atlanta, and preparing a new Perl blog post for Tuesday.
Standups don’t have to be synchronous. I’ve been on distributed teams that worked very effectively by posting their daily status in a chat room.
At a previous company, we’d do async standups (in chat) some days and sync standups (video cal) other days. I always preferred the async standups since they were more in-depth. Yes, I can look at Jira and tell you’re working on “the widget”, which is what they’d say in person for time constraints. But in chat, they can include links to code or docs that they’re struggling with. Or I can respond with links to code or docs to help out.
And 7 hours later in the day, I can go back and consult the chat if I found something relevant in my own work.
There’s a Reader View setting in the mobile Twitter client as well as some RSS newsreaders like Reeder. It’s great when you want to skip all the noisy stuff and get straight to the text.
Not true for Perl: FatPacker can bundle pure-Perl dependencies, and PAR::Packer will even go so far as to bundle compiled XS and C architecture-specific libraries along with a full Perl interpreter.
Nice. Worth emailing the author? By the looks of it they keep their post up-to-date.
Yep, just did.
Welcome to lobsters! You seem to be only posting pieces you authored and not contributing comments or other stories. This is something we frown upon here, and can lead to your pieces getting marked as spam or, in the absolute worst case, your site being domain-banned.
Sorry about that. I will participate more.