Michael Gueterman writes:

>In the "brave new world" of Microsoft Long Filename support, a 'blank' is in
>fact a valid filename character (I use it A LOT anymore when naming
>files).  I
>truly believe I understand the ramifications of including a space in the
>filename
>for many of the parsers out there, but for "NT Interoperability" (and
>other OS's),
>the space needs to be included as a valid character.

Natives to the place that Michael calls the "new world" (that is,
Macintosh users) have dealt with this situation for 14 years. Here's how:

1. Routines that take filenames as parameters always use Pascal-style
strings (equivalent to HPFOPEN item 51). This may solve some of the
internal issues Jeff mentions, but leaves the problem of the many
programs that use FOPEN (and FRENAME, FLABELINFO, and so on).

2. Those few programs with a command-line interface (e.g., MPW, Apple's
non-GUI development environment) use both quoting and escapes, though
quoting is the norm. For MPE, quoting has the advantage that very few
existing command files will be broken. The unquoted special characters,
including blanks, retain their existing meanings. Only scripts that do
LISTFILEs of Posix directories to files and then read the resulting file
as input will be affected by this. CM commands will also be unaffected in
this scenario.

It should be easy enough to enhance the CI's filename pattern matcher to
understand this syntax, and to provide a routine that would convert a
pattern thus matched into a Pascal string with quotes removed and escapes
interpreted. Adding the somewhat arbitrary rule that escapes must only
occur in quoted strings would improve compatibility.

One thing that will help to port the LISTFILE-type command files is a CI
function that takes a string and returns it "sanitized" -- quoted, and
with escapes if necessary. The command file writer can apply this
function to strings that are currently extracted from a file by record
position. MPW provides an option to do this on its list-files command,
also to assist in creating scripts. Exposing the inverse function (which
must exist somewhere in order for directory searches to succeed) would be
nice as well.

As far as the non-Pascal style intrinsics go, does anyone use FPARSE to
parse filenames before passing them to FOPEN and the like? If most people
do (which I doubt), changing FPARSE to recognize the quoted/escaped
syntax could be a way out. Teaching FOPEN/FLABELINFO/FRENAME and so on to
know about leading quotes could also solve the problem. Admittedly, this
will break programs that pass a null filename by using a quote as a
delimiter! I note that I can't do something like:

  FILE foo=./fum:m5.optc.com

so perhaps quote-plus-colon isn't an issue.

MYCOMMAND parsing may not be much of a problem. If FOPEN is trained to
deal with a leading quote as it now deals with ./, then routines that
call MYCOMMAND with the standard MPE delimiter set will get the whole
filename, quotes and all. MYCOMMAND would have to be trained to
understand escapes for this to work, though, which would have unknown
side effects. Perhaps it could "know" about escapes only if the escape
character isn't in the delimiter set.

-- Bruce



--------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
[log in to unmask]                   |     -- Edna St. Vincent Millay