Jeff gives away:
>Another consideration is that you can supply "!varname" in the middle
>of a filename passed to fopen.  If we make the APIs unaware of escaping
>rules, how do we: a) retain this functionality, or b) support "!" in
> filenames?

Yeah, but this is so amazingly obscure that I'm not sure more than two or
three people who read this list even know you can do this.  It's
always struck me as a bizarre feature.  Does anyone actually use it?
Do you know why it was put into FOPEN in the first place?

I still don't think you can change the FOPEN semantics to require a
null filename terminator, since I've rarely seen programs use
null as the FOPEN terminator.  It used to be that people would use all
sorts of things, but over the years you would occasionally get bit by
something like the NS Environment filename extension that added ":" as
a valid filename character.  From my experience, the most common FOPEN
filename terminator today is the space, with ";" being popular too, and
a fair number of non-terminated filenames that just happen to end with
invalid junk.  A quick survey of what all the language runtime libraries
that call FOPEN (don't forget CM!) might be interesting.

The problem will come when any program which allows the user to enter a
filename gets given an escaped Posix name.  Someone will enter "./foo"
and the program will pass this to FOPEN, and since there just isn't
going to be a null at the end, the program is going to build a file
which is named ./foosomething where "something" probably starts with a
a space and has an assortment of junk characters after that.  In an
environment where spaces are used to delimit filenames, the "junk"
may be another valid filename, leading to some very interesting errors.

Either that or the user will go insane trying to figure out why the
program keeps saying "./foo doesn't exist" when the user can see
quite clearly that there is a file there by that name.

So I still vote for not being able to get at UNIX style names from
FOPEN.  We're not raising the wall between Posix and MPE, we're just
lowering the ground on the Posix side of the wall a bit.

If you want to find out the effect of supporting UNIX filenames in
FOPEN, change the next Express Release to fail every FOPEN that would
behave differently if FOPEN supported funny characters and see what
happens.

G.