On Apr 21,  5:22pm, Michael L Gueterman wrote:
> Subject: Re: Extending Posix filenames (long)
...
> >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
> 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.

I tend to agree. I imagine that we will have to support a blanks as
legitimate filename characters.

I was talking to Gavin about this issue and he had a pretty good idea.
If we are willing to drop one of my assumptions and maybe add a new
syntax value to HPFOPEN then we might solve about 90% of the problem
with only 10-20% of the effort.  Here's the idea:

   Assume that the CI does not need to be able to reference all filenames
on the system.
   Assume that the POSIX shell can reference *all* filenames.
   Assume that these extended filename characters are only permitted via
the shell and POSIX APIs.

   From this base we have two possibilities:
   1) the existing "POSIX" syntax (*not* MPE-escaped syntax) is extended
to support all the special characters we need, or
  2) we add a new syntax called "UNIX" to MPE and to HPFOPEN.  We change
the POSIX runtime library to call HPFOPEN with the new UNIX syntax option
(rather than the POSIX syntax option used today).

   PROS:
-  the shell already supports an escape char ("\")
-  the greatest demand for this extension is to make porting unix apps
easier, not from the MPE side
-  we don't have to do all the work needed to design an escape char into
the CI and other supporting areas

... and I saved the most compelling reason for last:
-  we have no (or very little) compatibility exposure: no UDC, JCL, script
or MPE application is affected!


  CONS (coming from a CI bigot):
-  the CI cannot "see" all possible files on the system as it can today
-  system managers are more forced into using the shell and utilities to
manage their systems
-  the "wall" between MPE and POSIX gets a little taller for this one case
(in a sense it is an anti- "POSIX smoothing" solution).

Comments?

Jeff Vance, CSY




--