Well, for one thing: the program doesn't handle any options (command-line arguments that start with '-'). And I think that's a pretty good reason for not using a module that handles command-line options! (:

For another, even if there was a module to handle "use these default prefix arguments if the first argument isn't a number," I doubt that using it would be any simpler than the two-line construct I used:

  unshift @_, qw( 3 6 nice -20 )
   unless  $_[0] =~ /^\d*\.?\d+$/;
[download]

Note that I left it to Perl to warn the user if their second argument "isn't numeric" (if the first was).

I suppose I could go for a more complicated (to implement, to use, and to explain) usage, but it didn't seem worthwhile. Maybe if I'd already picked one of the many, many command-line option modules as my favorite and committed the details of how to use it to memory, then I might have gone that route without much extra work.

Just like I sometimes use named arguments to subroutines if there is enough reason but, if some order of arguments "makes sense" and there aren't very many, I'll just use the simpler positional arguments.

Even trying to think in terms of Getop:: command-line design, I don't see a usage that I really prefer. For example, something like one of these:

breathe [-r RUN] [-s SUSPEND] [-n "NICE OPT"] CMD [ARG ...]
breathe [-r RUN] [-s SUSPEND] [-n] [NICE OPT] CMD [ARG ...]
[download]

would mean that I could specify one or two non-default values while using the other default(s), but I prefer to specify both WORK and WAIT together if I change one (their ratio is more important than their individual values but having the user specify a 'ratio' and 'granularity' just makes it harder to explain).

And I don't like requiring quotes nor splitting '-n' (for 'no default "nice -20"') from specifying the replacement 'nice' nor reimplementing nice's option handling (not shown).

And I'd have to remember 'r' for 'run'/'resume' (not 'w' for 'work' nor 'e'/'x' for 'execute' nor 'c' for 'continue' ...) and 's' for 'suspend'/'sleep' (not 'w' for 'wait' nor 'p' for 'pause' nor 'd' for 'delay' ...) or I'd have the same problem remembering '--run' etc. While I have no problem remembering 'work then wait', since that is how it must happen (you can't spawn a pre-suspended subprocess) so I don't have to consult the usage message.

Now, if I one day want to add another option, I may decide it is worth splitting things up. It is certainly near the edge of that point. :)