This is a nice idea. However upon request, here are some detailed suggestions.

First of all I would suggest that you use Config to find the fallback:

use strict;
use Config;
use vars qw(%Config);
print "My default pager is $Config{pager}\n";
[download]

That will make your code substantially more customizable. And if someone doesn't have less on their system (such do exist) they won't go directly into hard recursion.

In the same vein I suggest having the editor be not just hard-coded but specifiable with an environment variable and possibly also with a command-line option. I usually use Getopt::Std for the latter. I would do the same with the color.

Speaking of the color, it is good that you handle the case where you cannot load colors, but I would suggest a brief message. Also I am wondering at your attempt to dictate valid colors. Why not just throw the color and then trap errors? Like this:

sub colorize {
  # Autoload here
  eval {require Term::ANSIColor};
  if ($@ =~ /locate Term::ANSIColor/) {
    print "Cannot locate Term::ANSIColor.\n",
      "Color support disabled\n";
    return;
  }
  elsif ($@) {
    die $@;
  }
  my $color = shift;
  my $escape_code = eval {color($color)};
  if ($@) {
    print "Invalid color '$color'\n";
    return color('reset');
  }
  else {
    return $escape_code;
  }
}
[download]

Next, why is your change_snippet_dir function inside your loop? Putting it there doesn't do anything useful.

Another detail. Should the sandbox be a directory with spaces in the path name, your glob is going to run into problems with shell semantics. I would suggest going with opendir and readdir - less danger of breakage.

Now a bigger change. Your main loop is very simple in concept. However you now have a manual syncronization job between printing your menu and writing your loop. This is going to be a problem. Instead I would suggest that you take a page off of Code that writes code and write the stuff currently in the body of your loop as structured text. Extract that into the real loop, then eval it. I would strongly recommend that if you go this way you test your eval for $@, and if there are errors dump the full text of the code you created.

Alternately you can write the information for the menu and the handlers in two hashes, then run an automatic check at load that the two data structures are in sync. Then you could, say, dispatch to anonymous subroutines like this:

  my ($case, $data) =(split /\s/, $input, 2;
  $case = lc($case);
  if (exists $handler{$case}) {
    $handler{$case}->($data);
  }
  else {
    do_default($input);
  }
[download]

There are also ways to combine the two approaches. One of the nicest is to use the fact that nested Perl data structures already look a lot like a structured data format. Take a look at the output of Data::Dumper to see what I mean. (I prefer $Data::Dumper::Indent set to 1, YMMV.) So you can have something like this:

@cases = [
  # etc
  {
    case => 'l',
    desc => 'co_or to change the menu item color',
    func => sub {
      print "change menu item color to: ";
      my $newcolor=<>;
      chomp $newcolor;
      $color=colorize($newcolor);  
    },
  },
  # etc
};
[download]

Think you can reconstruct your loop from that? :-)

Any way you cut it, a long-term maintainance problem is going to be keeping the description in the menu in sync with what the loop does. If your program will (and you know it will) remain small, then solving that is unneeded work. But if there is a good chance it will grow or change over time, restructuring so that the information that belongs together will stay together is worthwhile.

Also a point that is too often forgotten is that while the work may not have been needed, being agressive about doing this kind of thing on small projects stretches you so that you have the skills when you need it later...