Ken asks:
> Get into the POSIX shell and execute the following commands:
>
> echo f\\\\\\\\\\n

shell/iX> echo f\\\\\\\\\\n
f\\

^Note extra blank line here.

I'm not sure why, but the escape characters are getting processes
twice.  Probably echo does it on its own in addition to what the
shell did.

So the shell passes "f\\\\\n" to echo just as it does for the ls
(see below) and then echo sees two escaped "\" characters followed
by a "\n" newline.  So you get out "f", two "\" and a newline.
I don't really see anything very confusing about this.  I can make
much more convoluted examples out of MPE CI syntax for variable
replacement.

>
> ls f\\\\\\\\\\n

shell/iX> ls f\\\\\\\\\\n
ls: File or directory "f\\\\\n" is not found

The ls result is trivial.  "\\" is simply an escaped "\" character,
so the ten "\" characters become five and that's what ls sees. I
don't see anything odd or confusing about this either.

The place that UNIX is different from MPE is that in UNIX there is
no operating system recognized escape character.  None of the
operating system APIs know about escape characters.  There is only
an escape character *convention* implemented by the shell. Just
because most of the shell programs use the same method you tend
to think it is something magic, but you could write a shell that
used a completely different escaping mechanism and it would be a
perfectly valid UNIX thing to do.

On MPE, it sounds to me as though we're talking about coming up
with an "official" escaping mechanism, one which might even be
recognized by Intrinsic APIs.  I think that perhaps this is a
BAD THING(tm) because it breaks the layering between the CI and
the Intrinsics.  The operating system APIs should not be concerned
with what is a CI presentation issue.

I don't believe that a change which will break *any* existing
customer code is acceptable.  As someone just pointed out, there
are people who have asked to turn Posix off because of the effects
it already has on their non-Posix applications.

I don't think we all agree on just what "Posix Smoothing" should
mean.  I think of Posix Smoothing as making it easier to port
things like Samba and "Posix compatible applications" (too bad
there aren't any :-) to the 3000.  Others seem to think of it as
making MPE and Posix work more closely together.  I think this is
a bad thing because it means that you must be trying to make Posix
more like MPE and MPE more like Posix.  Fooey.  Posix is Posix and
MPE is MPE.  Any attempt to push them towards each other is going
to break things, and what is worse is that it will increase the
complexity of the MPE environment again which is something we *don't*
need.  I think if you want filenames with spaces in them, and other
such UNIX/PC nonsense, that it will be perfectly fine for these
files to only be visible/accessible from programs which know how
to access them, which means the Posix shell and not the MPE CI.
You can always copy a file to a name that MPE can understand, and
you can create a symbolic link from an MPE compatible name to a
weird UNIX name, and perhaps :FILE can be extended to support some
kind of escape or quoting mechanism to allow file equating to a
funny name.  I see no reason for FOPEN to allow access to UNIX
syntax names.  MPE-Escaped syntax is fine.  If you want to have
UNIX/PC weird names, you're going to have to use HPFOPEN to get
to them.

If we didn't HAVE to allow UNIX and PC style names in order to
make Samba and similar things work, I don't think we would ever
want to do it.  If someone says that they must have spaces in
filenames because they're just going to die if they can't have
a filename like "\SYS\PUB\My Documents\A Very Good File" then I
say tough.  Let them live with "My_Documents" or some other
valid *Posix* name.  Just because we have to offer these files
with bogus names food and shelter doesn't mean we have to invite
them into our homes to live with us.

G.