Hi all,

I'm passing on my comments to John Korb's private reply.

Jeff V.

To: John Korb <[log in to unmask]>
Subject: Re: Extending Posix filenames and walls

On Apr 25, 10:29am, John Korb wrote:
...
> Are the single quote (') and double quote (") characters valid characters
> within a UNIX file name?

Yes.  From the shell you need to escape the quotes with a \, eg.
   touch a\'b\"c
creates a file named a'b"c

> I guess what I'm really asking is, would enclosing UNIX file names in
> quotes solve the problem, sort of like:
>
>    :rename trdoctoc,"./training/training document index.html"
>
> Yes, the above would require a change to MPE syntax (the parser would
> have to allow quoted file names in all commands which include a file name
> as a parameter), but it would also mean that MPE could access ALL files on
> the system.

I have a couple of comments:
1) quoting a token is not really any different from having a single
escape char, at least from the perspective of the work that needs to be
done internally and wrt the issue of pattern matching (see 3 below).
However, quoting is less general than an escape char and that is
an advantage, since I imagine that we will run into lots of unexpected
uses of an escape char!

2) Today, all NM parsed command accept quotes. Eg today I can enter
   :PRINT "myfile", '*lp'
and all work fine.  CM parsed commands (like BUILD) generally will not
allow quotes today and would need to be changed.

3) Given 2) above we have a compatibility issue for NM parsed commands
that accept wildcarding.  Eg
   :LISTFILE "./a@b",2
Does this mean list all files starting with "a" and ending with "b",
or the file named "a@b" -- since @ would be a legal filename char.
Internally, we need to teach our pattern matching code the difference
between '@' meaning all char match vs. '@' meaning literally the '@' char.

> Those using the current unquoted syntax would be
> unaffected (unless I'm missing something).  It would mean a
> differentiation between what is acceptable for POSIX file names (the
> existing unquoted syntax) and what is acceptable for the extended [UNIX]
> file names, namely, UNIX file names containing the extended characters
> would have to be enclosed in quotes of some sort.

We have discussed a bit about introducing a 4th syntax -- UNIX.  We would
them be able to move apps/command/utilities to unix syntax over time, as
needed -- but you make a valid comment below!

> I guess that after dealing with UDCs and command file parameters where
> the MPE parser doesn't always treat input the way you want it to, forcing
> you to enclose parameters in quotes, I see quotes as a way to keep "the
> wall" between MPE and POSIX and UNIX low, and yes, I consider "the wall"
> an important issue.

Actually, the CI has some deficiencies wrt to quoting, parameters and
variables today.  These problems would become more prevalent with your
quoting idea.  I do agree that it is very valuable to keep the mpe/posix
wall low.  Did you read my post from last night where I suggested we may
be able to do reduce chances of compatibility problems and keep the wall
low?

> I guess if the quoting of UNIX file names would be too difficult, the
> "UNIX file names are allowed only in FILE equates" would be better than
> nothing.

True, at the expense of a higher wall, but at a much lower engineering
cost to CSY.

> Then again, perhaps the first implementation could be to allow the new
> file names (from MPE) via FILE equates, with the promise that later
> patches and updates would expand access to other MPE commands and subsystems.
> Hmmm.  But in what time frame.... After all, we are still waiting for the
> ability to "text" and "keep" POSIX file names in EDITOR, and use POSIX
> file names in FCOPY, DSCOPY, etc.

Valid point!
...
> Which since the application is Windows, means no Windows.
> With all the trouble calls I've placed, I can't wait to see my long distance
> phone bill...

Jeff

--