So there's the base directory of the script. I wouldn't want output there. ... would you rather put such a thing on our one and only subdirectory or split input and output into deparate directories?

Here's an idea for how to handle a script with a library.pm file or two that goes with it:

• Say /home/user is the base directory.
• I put my script in e.g. /home/user/myscript.
• Libraries (.pms) could go in the same directory, or in /home/user/myscript/lib, that doesn't really make a difference for small scripts - if you've got a lot of .pm files then a lib dir is a good idea.
• Ideally, /home/user/myscript is also a git working copy - in which case input and output data doesn't really belong in that directory anyway, as otherwise it'd have to be added to .gitignore.
• The script can be made to not worry about which directory it is located in using code like this:

  use FindBin;
  use lib $FindBin::Bin;
  [download]

  Or, if there's a lib subdirectory, using the following (platform-independent) code:

  use FindBin;
  use File::Spec::Functions qw/catdir/;
  use lib catdir($FindBin::Bin, 'lib');
  [download]

• You can put your input data in e.g. /home/user/mydata, cd to that directory, and run your script with e.g. perl ../myscript/script.pl input.txt, and it should generate its output in the current directory.
• If it's a script you use a lot, and you don't want to type out its path all the time, you could add it to your PATH. For example, on a couple of my boxes, I have lines like this in my ~/.profile: test -d "$HOME/myscript" && PATH="$HOME/myscript:$PATH" (the script needs to be chmod u+x for this to work).

Should I go update that on the original post?

I think in this case you don't need to, it's just for future reference, thanks.

in your code tags you've included the command-line invocations that I'd have to trim

I tend to think that it provides context ... Might pre tags work here?

Yes you're right - I didn't mean to make it sound like it's not a good idea, context can certainly be useful in some cases - the main point was not to put it in the same <code> tag as the code, to make downloading easier. <pre> tags have the issue that HTML and PerlMonks special characters have to be escaped (as you can see your <pre> tag has been rendered with links in it), so two separate sets of <code> tags work. Or, here's how I might have written that post (note you can use <code> tags in paragraphs as well):

Here is the script 3.rm.pl, which I run via ./3.rm.pl:

#!/usr/bin/perl -w
use 5.011;
...
[download]

And here is the output:

["abcdef", "abcdefg", "abcde", " bcdefgh", " bcd "]
["abcdef", "abcdef", "abcde ", " bcdef"]
...
[download]

Also, command lines like cat or perl script.pl are simple enough that we usually don't need to see them, it only becomes important when there are additional arguments involved. (And for some questions, it can be relevant whether a script was invoked as ./script.pl or perl script.pl, but that's not too often.)

What I seek to do is pass the first test...then others....

Sometimes it can be very useful to write the tests first, as it forces one to think about the API and what the output should ideally look like.

Can't use string ("abcdef") as an ARRAY ref while "strict refs" in use at ./3.rm.pl line 59.

getsubset expects an array of arrays, but $out is just an array of strings. Assuming you want each character to be a "column", you could do $out = [ map { [split //] } @$out ]; after $out = make_rectangular(..., or you integrate it directly in the push in your make_rectangular like so: push @out, [ split //, sprintf "%-*s", $maxlength, $trimmed ]; - either of those changes make your test pass. (Note you should call done_testing; after your tests.)