Mike writes:

> While not having time to ponder everything you mentioned, this one

ditto.

> >Issues:
> >-------
> >1) intrinsics like FLABELINFO, FOPEN, FRENAME, (more) expect a delimited
> >filename and support the MPE-escaped syntax.  Today an application can
> >FOPEN("./abc$zz ") and open ./abc.  Tomorrow the $ would be considered part
> >of the name so fopen would try to open "./abc$zz" (assuming blank is still
> >not a legal name char).  Is this OK since most applications use space, null
> >or cr as the filename terminator.  However, I know that the shell uses a
> >"$" as a name terminator.  (yes this make the Java work more interesting!,
> >and in MKS' defense, we recommended that char to them, for some reason?)
>
> 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

I agree with Mike that a blank must be a legal filename character.

Don't confuse the question of what characters are legal in filenames
with the problem of how to pass filenames into an intrinsic!

If we want a robust filenaming capability, we have to allow everything that
HP-UX allows.  This includes blank, tab, linefeed, and carriage return!
(But it appears to exclude one character: null (thank goodness!))

Taken the above as a given, as I believe we must, we ask "how can we specify
arbitrary filenames in existing intrinsics?".

Let's take the file whose name is the three characters: "F", " " (blank),
"T" as an example...

For FOPEN, we have only two answers:

   1) we can't ... I don't think this is acceptable

   2) we introduce the concept of an escape character, like the Unix "\"
      (backslash).

      We could open the file by passing FOPEN a string of 5 (or more) bytes like:

          "F\ T "     or    "F\ T"<null>   or   "F\ T_"

      (I.e., the standard concept of a terminator character *STILL* applies...
      in fact, we need not change the set of FOPEN terminators *AT ALL*!)

      (If we want to specify the file "\" (i.e., single character: backslash"),
       that would trivially be "\\ " or "\\<null> or ...)

For HPFOPEN, we have several answers:

   1) Item # 2  (user-specified delimiter, text without the delimiter,
                 user-specified delimiter)


          "-F T-"   or   "AF TA"   or    "<null>F T<null>"
                                         (the <null> means: a null character...
                                          the "<", "n", ..., aren't in the string)

   2) Item #51  (Address of a Pascal string is passed ... because there's a length
                 count, the contents can be arbitrary, with no need for
                 termintors or escape characters).


In the discussion of expanded filename rules, there's really only *one* question
we should be asking:

   Do we want to add an escape character (and parsing of it) to existing
   CI commands?

That's it, really.  We shouldn't be asking "what characters should be in
a filename"...that was answered years ago by Unix.  We don't have a choice there.

(The secondary question, should FOPEN be expanded to allow the new characters
is a "yes".)

Stan Sieler
[log in to unmask]