Hi all,

I am forwarding a reply from Tony Furnivall on this topic.

Jeff
--- Forwarded mail from Tony Furnivall <[log in to unmask]>

At 04:26 PM 4/21/1997 -0700, you wrote a lot of stuff, including:
>4) There are some internal issues: if we teach our filename parser to
>recognize an escape character (like "\") then we need to know what to do
>with all the "\"s in the filename.  If we strip them out and then pass the
>filename to our pattern matching routine, the "\@" becomes "@" and this
>will not produce the correct result.
>
>OTOH, if we leave the "\"s in the filename, teach our pattern matcher about
>escaped chars, then we need to tell the directory code to strip them out
>before accessing the directory, which is contrary to the directory philosphy.
>We can have our filename parser return both names (with and without "\"s) and
>use the correct version for various operations.  This seems ok, but affects
>lots of code (both NM and CM)!

I guess I'm glad that I've reached the age where I say (with relief!)
"..such knowlege is too wonderful and excellent for me, I cannot attain unto
it."
But what would the performance hit be if instead of a single (permanent?)
escape character, there were an HPESCAPECHAR variable which would be
de-referenced immediately prior to any operation involving the escape value.
This would allow you to use a variable reference rather than the literal
(hence the concern about performance), but would give you more flexibility.

(Of course, I may be so far off base here, that I'm in the next ball-park,
or maybe that should be cricket pitch!)

Tony

--