On May 5,  6:12pm, Craig Fairchild wrote:
...
> > 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 wasn't explicit in saying that the CI (at least at 1st release) would not
support an escape char (like "\").  And that one of the "features" of this
proposal is that the APIs don't need to be taught about escaping.

> 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.

True.  We figured the sys admin would need to learn about ACDs, CWD and
MPE-escaped syntax, but s/he would not need to be unix nor shell literate.

> 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.

I don't know if the requirements of the sys admin have changed much in the
last 5 years or not.  My guess is that most relatively new sys mgrs have
unix experience.  The old time MPE admins may or may not have unix
experience.  Is it acceptable to require (due to trade-offs in the design)
that sys admins who are managing systems that are running unix apps be
somewhat shell literate?

> 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,
I think this can be done with our current (albeit hacked) "java"
implementation

>  2) rename any file on the system
>  3) copy any file on the system
ditto, ditto

>  4) backup any file on the system
didn't try that

>  5) change or set the security attributes of any file on the system
nor this!
..
> Now there may be niftier and better ways of doing these tasks, but they
should
> all be able to be done from the CI.

This is the issue I brought up earlier where one could argue that we are
increasing the height of the proverbial POSIX/MPE wall.  I prefer to see
it, as Gavin suggested, that we are lowering the unix side of the wall.
I think this is one of the crux issues!  If the majority insist that the CI
be able to reach ALL strangely named files on the system (which it can today)
then the CI needs an escape char and so does FOPEN, FLABELINFO, FRENAME, and
many more (Stan has a list).  The effort goes up significantly.  MYCOMMAND,
coreparser and several other routines are impacted.

> > 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 $....

I am interested in feedback on this exception.  Do we need to restrict $
from the beginning of all filenames, or can we say that we have certain
reserved filenames, like: $NULL, $OLDPASS, $NEWPASS, $STDLIST, $STDIN, $STDINX,
$STDERR, and $<some directory names>?

> > 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....
> The proposal above would limit MPE-escaped syntax to only be able to express
> a subset of the possible HFS syntax names.

Well, I think MPE-escaped syntax can express ALL possible names depending on
the API.  HPFOPEN - MPE-escaped syntax item, with <delim>name<delim> works
perfectly well.  FOPEN (and several others) has the terminator problem.
My proposal can break existing apps that call FOPEN with an MPE-escaped
filename, using a printable terminator like '$'.  Craig's proposal, below,
doesn't break existing apps since he introduces a new MPE-escaped-prime
syntax.  To take advantage of this new syntax you need to modify your
app.  Also, pgms that accept user-input filenames need to be checked
to ensure that they only use a null terminator, since the user-input name
could be ",./some$thing,nasty".

> 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.

The CI could change to support this new syntax and easily terminate all
filenames with a null.  I like that command line filename extraction
works mostly in a compatible manner:  Eg
   :echo abc>./foo$bar
writes "abc$bar to the file ./foo ...whereas
   :echo abc,./foo$bar
writes "abc" to file ./foo$bar.
Of course, today the above echo is legal and would have written  "abc,$bar"
to file ./foo.  It is very difficult to not break anything!
...
> Fortunately, as long
> as we have the backslash "\" escape character, the user can always terminate
> the name themselves. Thus, an example might look like:

As I said, my poroposal didn't have an escape char for the CI or for any of
the APIs. I understand your use of "\0", but this interpretation requires
an additional escaping rule: "if the char after the escape is numeric within
the ascii range then use the binary equivalent".  This special treatment
is diffrerent from how the hp-ux ksh works.
...
> Well, it's an idea, I'm not sure if it's a good one or not.

I think it is a good idea that deserves further discussion!

> > 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".

Yes, and the escape would have to be processed by FOPEN, thus the escape
char is not a "shell" metacharacter.  This distinction matters.  With Craig's
new escape syntax, above, FOPEN et. al. can accept arbitrary strings of
characters without interpretation.  This makes it very easy to write apps
that use these extended names, even apps that prompt for arbitrary
filenames.  If the APIs interpret metachars, like "!", then apps cannot
simply pass the name down to FOPEN; instead, the apps have to process
the filename to ensure correct escaping.
...
> 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().
                                                  ^^^^^^^
Excellent point!
...

Thanks for the thought provoking feedback,

Jeff V.

--