Actually, I'm pretty sure that it is working. It's just that you are discarding your changes by sometimes using $new, sometimes using $aphor. Specifically:

$new= join "\n\t", @sect;
&shortenlines;  # uses $amphor for input instead of $new.
[download]

You'll gain so much by using proper parameters and return values. It is much harder to make a good program that uses globals and exit() all over the place (but not impossible, says Wassercrats).

ikegami:
Bingo! ...and thank you!

$rest = "\n\t" . $new;    #see ikegami's reply; was ". $aphor"
[download]

Now I will give both your alt solutions the study they deserve (something, I've been holding off on in hopes I could find my own errors).

I think I understand the underlying difference in approach lies in your design of REMOVING the matches from the front of $new, so each iteration has to start the count at an appropriate point while my

@new  = $rest =~ m/\G(.{$min,$max}[\x20.])?/gsx;
[download]

is either
a) an abuse of \G (owls, p15 sez "Beginning of current search" (emphasis supplied) whereas I (mis)read other docs to imply that it reset the start of the search
or...
b) use of the "?" quantifier is wrong.

And even if neither of those proves out, many thanks, both for the wisdom imparted and the implicit encouragement.

I didn't use \G as a way of avoid using $'. I could have come up with a way of using \G and not using $', but I chose this way.

I did get rid of $max+6. It makes no sense. I think it was added as a hack to make $min look like it's working better than it really does. In fact, $min is totally useless unless you force a break mid-word whern there is no space between pos $min and $max (which you don't do). Until $min's function is better defined, I just dropped it completely from my version. I suppose s/^(.{$min,$max2}\S)\s+//s would probably do what you have in mind, because of the else clause.

Oh dear.

Allow me to quote from talexb's reply to a post earlier today:

I'm guessing that you won't get much (serious) help on this -- you're asking us to spend significant time to debug a piece of code. You've come to the wrong site for that. Here's what this site (and community) is about: you bring your boiled-down, condensed, pithy Perl question to us, and we give you lots of varied answers and different approaches. You learn something, and perhaps we do too. I suggest you go away and do some work on your question, and come back when you've narrowed it down a bit...

We don't want to see your entire code (in particular, when you've learned a little more about Perl, you'll be ashamed about stuff such as:

if ($subscript == 1) {
  $aphor = $aphor1
} elsif ($subscript == 2) {
  $aphor = $aphor2
#... up to and including elsif (subscript == 7) { .. }
[download]

but as you're learning, at present, that's OK).

But what's not OK is to post the whole mess here. Note my emphasis of talexb's 'boiled-down, condensed, pithy' (if you don't know what 'pithy' means, well, er... it's pretty much the same as 'condensed' (or 'boiled-down' :) ).

I simply don't have the time to look through all of your 135 lines (in my editor) of code, and I imagine that most other Monks don't, either.

The moral is: Condense it! Boil it down! Extract the pith!

First, for example, your question has nothing to do with command-line processing, so take out all the stuff about @ARGV.

Second, we don't need to know how you define and select your aphorisms according to user input. If you have a problem with parsing user input, make it the subject of a separate post, not one entitled 'unexpected behavior with split'. This means that you could replace 43 lines (in my editor) of code (including the @ARGV stuff) - from if ($subscript == 1) { to the '}' just after die "ARGV out of range"; - with just one line, namely:

where 'whatever' corresponds to one of the aphorisms that you are having problems with.

How to post condensed (boiled-down, pithy) code: Let's say I write some code that Perl doesn't want to compile (a regular occurrence, I assure you). After examining the error messages, and correcting my most ridiculous mistakes, and other stuff, if it still doesn't do what I want, I postulate that there might be an error in the line:

So, I create a new perl file (I call it 'test.pl', YMMV):

use strict;
use warnings;
my $str = 'aa~~bb';
my $splBRK = '~~';
my @sect = split /$splBRK/, $str;
print "<$_>\n" for @sect;
[download]

Well, it seems that test.pl (after trying as many test cases as I can think of) works as expected , implying that the problem is elsewhere in my code. So, ikegami++ (how I envy his/her patience!) is probably right.

I could go on, but I think that a Tutorial entitled 'Basic Debugging' (or something...) might be in order. A lot of interesting stuff has already been posted in PM, such a tutorial could be mainly just be a synthesis of these nodes, but time (as ever) is not extensible...

dave

Dave:

Thank you too. ikegami did me the kindness of offering many corrections/suggestions/tactics on the original code... of which, even as a learner, I was well and truly ashamed once I understood his points. I'm similarly chastened, but also more educated, thanks to your pointers.

And as my last reply noted, I now know the title was hopelessly hapless. For that too, apologies to you and all others who stumble upon it.

I would welcome a reference to any tutorial you care to recommend on useing a debugger effectively. print statements (only a few of which made it into the posted code) go only so far... and regrettably, I'm still finding the docs for activestate's debugger almost impenetrable.