# Note we assign the return value of the sub to $txt
   $txt = escape_html_character($txt);

   sub escape_html_characters {
      my $string = shift;
      $string =~ s/...some chars here.../...some escape.../g;
      # Note we return the modified string
      return $string;
   }
[download]

The long answer:

• You probably want "use warnings" turned on.
• You don't really want to be using 'local' and 'local $_' in modern code. So-called 'lexical' variables declared with 'my' are much safer and less likely to cause problems like this.
• Escaping characters like this is likely to be a solved problem, done by people who are likely to have exhaustively gone through all needed characters, so I'd first look for a module to do this on CPAN. In fact, within the CGI module you're already using, there is the 'escapeHTML' function which looks like what you need.

        # Put in HTML-friendly characters for any odd characters
        &ncw_com_library::cleanup($attr_descr);
[download]

You expect your cleanup() subroutine to do inplace edits of its argument, instead it takes a copy and returns it modified. Your $attr_descr doesn't get altered.

Don't use the & prefix for sub calls, unless you know what it does and you need that because you do know ;-)

        # Put in HTML-friendly characters for any odd characters
        $attr_descr = ncw_com_library::cleanup($attr_descr);
[download]

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Thanks to jbert, grep and shmem for the excellent pointers and explanations.

I had looked at the various ways to call the sub (do I put in & or leave it out), but didn't think in this case it mattered.

The simplest solution for me (based on the existing code and needing to add cleanup code elsewhere) was to let the CGI and HTML:TEMPLATE modules handle it.

Yep, shoulda thunk more 'bout not re-creating the wheel. :-)

THANKS!

I had looked at the various ways to call the sub (do I put in & or leave it out), but didn't think in this case it mattered.

It didn't matter. I'm not sure why that was pointed out to you. The basic thing is that, to modify a passed parameter, you need to do it via @_, like

# surround all uppercase characters in the passed parameter with *'s
# and all lowercase characters with _'s
# (modifies parameter in-place)
sub transmogrify {
   my $string = $_[0];
   $string =~ s/([A-Z])/*$1*/g;
   $string =~ s/([a-z])/_$1_/g;
   $_[0] = $string;
   return;
}

$text = "I met this guy, and he looked like he might have been a hat c
+heck clerk at an ice rink, which in fact, he turned out to be.  Let X
+ = X.";
transmogrify($text);
print $text;
[download]

Or you need to not try to modify the parameter, but instead return it, and have the caller call the sub appropriately:

# surround all uppercase characters in the passed parameter with *'s
# and all lowercase characters with _'s
sub transmogrify {
   my $string = $_[0];
   $string =~ s/([A-Z])/*$1*/g;
   $string =~ s/([a-z])/_$1_/g;
   return $string;
}

$text = "I met this guy, and he looked like he might have been a hat c
+heck clerk at an ice rink, which in fact, he turned out to be.  Let X
+ = X.";
$text = transmogrify($text);
print $text;
[download]

minor nits, OT of your now-solved chief question:
First..

...because the nasty characters my customers insist on typing into their descriptions occasionally makes the HTML page break.
For example, I want to exchange a tick mark (') with (& rsquo ;) ...

You're on the money in saying "customers" sometimes insert "nasty characters." They certainly can and do and sometimes that will bork stuff... but I don't know any way a simple tick could, in your word "break" the HTML page; an ASCII "'" does NOT (in my experience) cause any issue with a browser's rendering. Perhaps this is merely incautious phrasing, but if not, I'd be interested in an example to clarify my understanding.

and, second... When posting two distinct bits of code, it would be well to enclose them in individual sets of <c>...</c> tags,

• for clarity ...and because,
• that way, the Monastery provides two separate "download" links.

Welcome to the Monastery! Perhaps the promptitude of the excellent replies above will prompt you to get a login.

They certainly can and do and sometimes that will bork stuff... but I don't know any way a simple tick could, in your word "break" the HTML page; an ASCII "'" does NOT (in my experience) cause any issue with a browser's rendering. Perhaps this is merely incautious phrasing, but if not, I'd be interested in an example to clarify my understanding.

Attribute values inside an HTML element, when you're using the same type of quotes around the element in question:

<img alt='Bob's Birthday Party' src='birthday.jpg' height='480' width='640'>

You might have the same issue with double quotes, if you're double quoting the values of the attributes.

You're right, of course and thank you. The apostrophe (as a straight tick) inside your single quoted alt would definitely be a problem.

However, my "incautious phrasing" perhaps led you to this.

I see no indication that OP was allowing customers insert anything inside .html elements, tags or values. (And -- aside -- he's fetching the data from a database, which might suggest the cleanup should occur before the customers are allowed to insert it there)

So, rephrasing:

...a simple tick (in the kind of data context presented by the OP) could, in....

And, again, thank you. That kind of good-catch may save much grief for some future reader presented with my ill-considered words
    ...and I surely hope this is more precise

  [
    [
    -key        => 'lang',
    -name       => 'Language'
    required    => 1,
    length_max  => 5,
    ],
    [
    -key        => 'from',
    -type       => 'EMail',
    emptyok     => 1,
    ],

    -key        => ['foo', 'bar']
    required    => 1,
  ]
[download]