On May 5, 11:16am, Jeff Vance wrote:
> Subject: Re: Extending Posix filenames
> Hi all,
>
> Here is the summary of what I've heard so far on this topic, and how
> I think we should preoced (and what we've already done):
>
> o  extended chars for POSIX/UNIX only - don't want to extend MPE-only
> filename rules.
>

I agree that the HFS syntax should simply be extended rather than defining a
new syntax type. Note that POSIX "compatibility" isn't something that an OS has
to worry about from a legal filename character set perspective. POSIX defines
the "portable filename character set" to be exactly what we have implemented on
MPE. However, this is really a portable character set from an application
writer's point of view. In other words, if you want your application to be
"POSIX compliant" then your application will only use filenames with characters
in this set. A specific implementation is free to support any characters it
wants, as long as it meets this minimum standard. We even went so far as to
enforce the portable character set rule of not allowing names to start with a
hyphen (-), even though this is really only an application restriction.

> o it is more important to support these extended chars now in the POSIX
> environment -- worry about what to do to the CI later.
>

I'm not sure I concur with this one. One of the basic tenets that we adhered to
in the POSIX program was that the system had to be able to be administered from
the CI by an SM or OP that had no specific UNIX, POSIX, or shell experience.
Perhaps the world has changed in the last five years, but I still see
occasional posts about disabling POSIX that make me think that there is still a
significant portion of our customers that want nothing to do with POSIX or
funny shells.

Because of this, I don't think that we have an acceptable solution until a
system manager can perform the following tasks from the CI:

 1) purge any file on the system without having to purge a whole directory,
 2) rename any file on the system
 3) copy any file on the system
 4) backup any file on the system
 5) change or set the security attributes of any file on the system
 6) hmmm, there's probably more, but I can't think of it right now

Now there may be niftier and better ways of doing these tasks, but they should
all be able to be done from the CI.

> o legal filename chars: a) for "POSIX" syntax: all printable ascii chars,
> b) for "MPE-escaped" syntax: same as POSIX syntax, c) for MPE-only syntax:
> no change.
>

Could I ask for one exception to this rule? I'd like to have a rule that says
that no HFS syntax name on MPE can begin with a $. A leading $ should be
reserved for expressing system defined files as it is today; $STDIN, $STDLIST,
$STDINX, $STDERR, $NEWPASS, $OLDPASS, $NULL, and a few others that are just
used internally. My concern is that these files already have a defined behavior
that should supercede other behavior. Note that $ is perfectly fine in any
other position, just not the first.

> o  filename terminator characters: a) for "POSIX" syntax: only a null is
> legal, b) for "MPE-escaped" syntax: all non-printable chars and token
> delimiters (like semicolon, space, comma, parenthisis, quotes) are legal
> terminators, unless quoted.  For MPE-only syntax: no change.  Note: token
> delimiters *are* legal POSIX filename characters and are also MPE-escaped
> filename terminators.  This means that POSIX filenames using these delimiter
> chars (like comma for RCS) may not be accessible from the CI -- but will
> be accessible from the shell.
>

The question of how to handle the MPE-escaped HFS syntax names is the most
difficult. We were exceedingly lucky that "." and "/" had HFS meaning and were
illegal beginning characters in the MPE syntax. This allowed us to have the
concept of "escaped" names - a means of naturally saying, "I normally want to
deal with good old MPE file name behavior, but sometimes I want to name this
other strange thing." We actually relaxed the name termination rules with
escaped HFS syntax names in that normally "_" and "-" could terminate a name in
MPE syntax, but would be considered part of the name in escaped HFS syntax.
This allowed all possible HFS syntax names to be expressed through the
MPE-escaped syntax.

The proposal above would limit MPE-escaped syntax to only be able to express a
subset of the possible HFS syntax names. I wonder if there could be a third
"escape" character (".", "/", and something else) which would indicate that we
wanted to use HFS syntax, and that the terminating character should only be the
null char (CHR(0)). For the sake of this discussion, I'll just pick a naming
escape character, though try not to get too hung up on it specifically - it
could be many different chars. Let's say that the new name escape character is
the comma ",". Using this new character, an interactive user would be able to
specify any HFS syntax name with MPE-escaped syntax. It would also be the
user's responsibility to make sure that the name specified was terminated by a
null char, since most applications do not do that for you. Fortunately, as long
as we have the backslash "\" escape character, the user can always terminate
the name themselves. Thus, an example might look like:

  ,./the $ file\0                  or
  ,/ACCT/GROUP/the $ file\0

As shown in both of these examples, the "," char would need to be consumed
rather than treated as part of the actual name itself.

Well, it's an idea, I'm not sure if it's a good one or not.


> o "!" in MPE filename passed to FOPEN must still work; however "!varname"
> in an MPE-escaped or POSIX filename will no longer references a CI
> variable, since "!" will become a legal POSIX filename char.
>

>From a purely external behavior point of view, I think that I'd prefer to have
!varname always be allowed and processed. However, if I really wanted to have
"!" as part of the name, it would have to be escaped, "\!varname". This would
be consistent with the CI rules about when to pay attention to wildcard
characters and when to interpret them as part of the name. Ruling out variable
substitution in HFS syntax names would be a regression in functionality
(whether or not it is actually used in this way, I do not know). Variable
substitution in HFS syntax names is valuable for the same reasons it is with
MPE names, maybe even more. It allows for customizable path names that aren't
available any other way since we do not support chroot(). With MPE syntax, file
equations can be used to produce a similar effect, but HFS syntax cannot use
file equations. Symbolic links also do not provide the same feature set since
they are seen globally by all processes, whereas variables act locally to each
jor or session.

>
...
>-- End of excerpt from Jeff Vance


Craig