It is not that hard either (unless perl is completely foreign to you).

Ironically just today I wrote a python script (using concurrent.futures) to batch re-encode 10gb of mp3 podcasts into 3gb of opus files to save space. Before I deleted the old mp3's, I did a quick file count of mp3 and opus files only to have 5 extra opus files... I beat my head really good trying to glue a bunch of bash stuff together but I could not find where the 5 extra opus files were coming from.

I defected back to perl. All I needed was an alphabetical list of all the files (there were many sub-directories), perfect for a little perl oneliner:

  find /podcasts/ -iname "* \.ogg" | perl -nle 'if( $_ =~ /\/([\w-]+.\w\w\w)$/) { print "$1"}' | sort >ogg.txt

Sure it looks hideous, but the explanation is easy: for 'perl -nle', the 'l' means process each line from stdin individually, the 'n' means no auto printing of the line, and the 'e' is basically the perl 'one liner' mode. Either way, each line comes in and is stored in '$_', I use a capturing regex to grab the file name without parent directory names, basically everything after the last '/' in a path that ends with a three letter extension (\w\w\w). The "captured" part of the regex ends up in '$1'. Also see 'perldoc run' for all the runtime one liner options.

(By definition, since you're looking for `.ogg` files, everything `find` finds will have a path that ends in a three letter extension.)

    perl -nle 'if( $_ =~ /([^\/]+)$/) { print "$1"}'

And it allows ",ogg" (dot not escaped so it is not extension), thankfully find provides /\.ogg$/

    $ find . -iname '*.ogg' | ruby -nle 'puts $1 if $_ =~ /\/([\w-]+\.\w\w\w)$/'

    find /tmp/test -type f -iname '*.ogg' -exec sh -c 'for f; do printf "%s\n" "${f##*/}"; done' - {} +

  /podcast/with/nasty'--c h a r$/and/stuff/track1.mp3

    $ i="/podcast/with/nasty'--c h a r$/and/stuff/track1.mp3"
    $ echo "${i##*/}"
    track1.mp3

    $ function remove_longest_matching_prefix () { echo "${1##$2}"; }
    $ remove_longest_matching_prefix "$i" '*/'
    track1.mp3

track1.mp3

  $ path="/podcast/with/nasty'--c h a r$/and/stuff/track1.mp3"
  $ echo "${path##*/}"
  track1.mp3
  $ basename "${path}"
  track1.mp3
  $ echo "${path}" | awk -F/ '{print $NF}'
  track1.mp3

    echo “${uglypath:t}”

The old school "cpan" command has not been recommended to be used for nearly a decade now. Maybe that is your issue?

Everyone just uses cpan-minus: http://cpanmin.us/ or "cpanm". It will install anything, if you have write access to the installed perl location, it will install globally, otherwise it installs packages into "~/perl5" then just do something like "export PERL5LIB=~/perl5/lib/perl5/" in your bashrc.

Or maybe you are talking about having to compile code in certain packages? Alot of stuff using ssl has C code which links against openssl which is always a pain.

Not sure what other issues you might be alluding to... There are some "packaging" tools to try to bundle and pin libraries, kind of like venv for python. I've never messed with them though. We just compile the latest perl binary and install all our needed cpan modules globally. Never worry about pinning since nothing is ever updated on cpan anymore...

I did not know that it was not supposed to be used, so that might explain my issues, but at the same time it did work for me on my machine, but had a hard time running my Perl script on a VPS, because I had to set everything up again and for some reason I ran into some errors.

I often ran into packages that failed to compile, too, yeah.

> Never worry about pinning since nothing is ever updated on cpan anymore...

Nothing makes it kind of sad. :/

But I agree with this, except for python