I'm kinda feeling this would be better in the Obfuscated Code section. :-/

I feel you. It was a struggle. Is there an easier way to list CPAN EXE_FILES?

Perl supports something new and weird, called a script. It's been around for just a few decades, so I understand you have never heard of it before. Essentially, you put your code into a text file instead of insisting to type half a kilobyte of code into the command line over and over again. Start the file with #! followed by the name of the interpreter, in your case /usr/bin/perl, followed by a newline. Put your code into the next lines. See also https://www.in-ulm.de/~mascheck/various/shebang/ and perlrun.

The following quote comes from about the same time:

"I don't comment my code because if it was hard to write, then it should also be hard to read."

Sounds familiar? Yes, disk space and memory once were a scare resource. The MUMPS people learned that the hard way, and so their code typically looks like this, even after more than half of a century has passed:

Q()
    N S,N,T,I,K,Q S I="K",S="11",K="l1",Q="R",T="K"
    I I=T D T
    Q:$Q Q Q
T   I I,S&K S S=S+K Q
[download]

(Source: Wikipedia)

Great news: We have increased disk space, memory and CPU power by several orders of magnitude since that dark age. You no longer have to fight for every byte. So feel free to add as much comments as you like, explaining whatever is not obvious in your code.

Oh, and by the way: Some clever people invented something called POD, a way to create nice-looking documentation from a few lines of text inserted into your perl code. Other people have copied and extended that idea for other languages, at least twice (Javadoc, Doxygen).

Well, actually, no REAL MUMPS programmer would ever use functions. "We have labels. We don't need no stinkin' functions." And the NEW command is something to avoid at all costs. "Adding scope to variables is for the weeks. We know our variables, and we know when we have to copy then to prevent overwriting." Plus, those lines are way too short. The first three lines should be combined into one. "Stuffing as much code into a line as possible makes the code run faster. The interpreter is line-based."

(And no, I did not make up these quotes. They are real, from a time when I had to write MUMPS code for a living - in THIS century.)

Alexander

EDIT: This code is wrong, see OP for correct version! Sorry...

It's much easier to develop one-liners on the command line because it can so rapidly scroll through history of revisions. I can get a few test runs deep into trouble fiddling around with it and get back to a working version by hitting the up arrow a few times. In many years I haven't found a more rapid, easier and fun way to explore and deploy the power of perl. After achieving my desire from the machine these mega one liners find themselves all sorts of places to extend the operating system with new commands and functions.

The way I'm posting them, dense and without triggering code wrap, makes it easy for me (and hopefully you) to copy directly from the webpage, to paste in a console. So you click download and see this gigantic one-liner that you want as a script? It depends on your operating system but for this script on Linux/Mac it goes something like this:

Control|Command + a to select all
Control|Command + c to copy selected text
In a terminal type: echo
Type one space
Control|Command + p to paste text
Type: | perltidy -st >cpanexe; nano cpanexe

Here's a handy blob of code to throw at a terminal that transforms itself into a proper script, saved to disk, opened in an editor. This can make any one liner into a script! Just echo a pasted one-liner to another one-liner via pipe and then pipe that to perltidy which you can direct to save a file and then open it in your favorite text editor:



echo perl -le'chomp(@_=`perldoc -T perllocal`);
# List EXE_FILES installed by CPAN
$_=join"\n",@_;@_=split/\"Module\"\s/;
@_=grep/EXE_FILES:\s[^"]+/,@_;for(@_){@x=split/\n/;
@x=grep/EXE|0m/,@x;push@z,@x}s/^\s+\*\s+\"([^\"]+).?/$1/ for@z;
@_=grep/EXE_FILES/,@z;@_=map{substr($_,11,length($_))}@_;undef@z;
for(@_){if(/\s/){@x=split/\s/;push@z,$_ for@x}else{push@z,$_}}
%_=map{s/^\S+\///;$_=>1}@z;print$_ for sort{lc($a)cmp lc($b)}keys%_'| 
perl -e'@_=<STDIN>;print qq~\#\!/usr/bin/perl\n\nuse strict;~.qq~
use warnings;\n\n@_;~'|perltidy -st >cpanexe;nano cpanexe
[download]

Result:



#!/usr/bin/perl -w

use strict;
use warnings;

chomp( @_ = `perldoc -T perllocal` );

# List EXE_FILES installed by CPAN
$_ = join "\n", @_;
@_ = split /\"Module\"\s/;
@_ = grep /EXE_FILES:\s[^"]+/, @_;
for (@_) {
    @x = split /\n/;
    @x = grep /EXE|0m/, @x;
    push @z, @x;
}
s/^\s+\*\s+\"([^\"]+).?/$1/ for @z;
@_ = grep /EXE_FILES/, @z;
@_ = map { substr( $_, 11, length($_) ) } @_;
undef @z;
for (@_) {
    if (/\s/) { @x = split /\s/; push @z, $_ for @x }
    else      { push @z, $_ }
}
%_ = map { s/^\S+\///; $_ => 1 } @z;
print $_ for sort { lc($a) cmp lc($b) } keys %_;
[download]

I don't see the problem with dense code. It makes sense to me because that's how it gets created at the command line. Perlmonks understand it just as well as their spoken language so i don't understand the criticism or why we're constantly hounded by the cult of whitespace. Learn how to use perltidy and the rest of your operating system to make it do what you want instead of complaining. It's much more productive! ☺

This is a one-liner! A tidy 20 lines. It gets 29 things done with perl to do something impossible:



chomp join split grep for split grep push s for 
grep map substr length undef for if split push 
for else push map s print for sort cmp keys




_{STOP REINVENTING WHEELS, START BUILDING SPACE ROCKETS!—CPAN} 🐪

"It's much easier to develop one-liners on the command line because it can so rapidly scroll through history of revisions."

That's what a VCS (Version Control System) is for (eg: Git, SVN, Mercurial etc). The added benefit is being able to much more easily read your code (because it's in a script), and it provides permanent revision bouncing (and commit cherry-picking, tagging etc).

It gets 29 things done with perl to do something impossible

It's not impossible. You should look up what that word means.

It's much easier to develop one-liners on the command line because it can so rapidly scroll through history of revisions. I can get a few test runs deep into trouble fiddling around with it and get back to a working version by hitting the up arrow a few times. In many years I haven't found a more rapid, easier and fun way to explore and deploy the power of perl.

For you maybe, it sounds stupid and time consuming, and looks awful. Thanks for perpetuating the meme that perl looks like line noise

Feel free to golf my code.

Ok.

perl -MList::Util=uniq -le "$,=$/; print sort( uniq( qx(perldoc -uT pe
+rllocal) =~ m(<EXE_FILES: (?:.*/)?(.*)>)g) );"
[download]

Note, I'm not actually a golfer. This is just my idea of concise code.

That's so dope, but it's incomplete. You forgot to split out lines with multiple records. I tried to extend your idioms up front but ended up post processing:



perl -MList::Util=uniq -le "$,=$/; @_= uniq( qx(perldoc -uT perllocal)
+ =~ m(<EXE_FILES: (?:.*/)?(.*)>)g); for (@_) { @x = split/\s+/; push 
+@z, @x} print sort @z"
[download]

_{STOP REINVENTING WHEELS, START BUILDING SPACE ROCKETS!—CPAN} 🐪