HP3000-L Archives

September 1997, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Vance <[log in to unmask]>
Reply To:
Jeff Vance <[log in to unmask]>
Date:
Thu, 4 Sep 1997 20:25:35 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (78 lines)
Hi all,

I want to get your opinions on the risks of the subject patch,
especially wrt potential compatibility issues.

The main purpose of MPEJXQ1 is to allow us to support newer versions of
Java.  The current version of Java uses "$" in inner class filenames.
There is reason to believe that in the future more extended characters
will be needed in POSIX filenames.  There is also a benefit to Samba.

When we support Java and Samba in FOS we will need the MPEJXQ1 patch
is FOS as well, but currently this patch is being released as a site
specific patch.

What does MPEJXQ1 do?
1) it allows POSIX and MPE_Escaped filenames to contain all printable
characters except for:
      "/" as a legitimate char rather than a component delimiter, and
      "\" being reserved for an escape character.
The rules for MPE-only filenames have not changed.

2) it allows the TO= paramater of the COPY command to accept a directory
name in addition to general filenames and ".group[.acct]" names.
The directory name must be in MPE_escaped syntax and contain a trailing
slash, e.g., :copy foo, ./dirname/

3) it supports the new FSYNTAX() CI evaluator function which performs syntax
checking on any type of filename.  More on this in a separate posting.

Number 1 above is the big issue.  In the shell there are no known problems
using any of the extended characters in any of the commands (although
there is a required companion MKS/shell patch - PX2JXQ2).

In the CI there are a few usability issues where inconsistencies are exposed:

  a) native mode commands allow filename parameters to be quoted (thus
     allowing you to specify blanks, commas quotes, etc. as part of the
     POSIX name), but compatibility mode commands do not.  Example:

:copy foo ,"./a=b'd"       <-- copy is a NM command
:listfile "./a=b'd",6      <-- listfile is a NM command
 /SYS/TMP/a=b'd
:build "./a,b"             <-- build is a CM command
       ^
Invalid character in MPE file name. (CIERR 583)  <-- filename starts with "
                                                     not a . or /. It is
                                                     considered an MPE name.

   b) some characters cause additional problems.
Many CM commands treat comma, semicolon and equalsign as delimiters.
Since these same CM commands cannot accept quoted arguments, it is
difficult to use a POSIX filename with these characters.

   c) FOPEN (and thus all CI commands that call FOPEN) treats a space
as a MPE_Escaped filename terminator.  All non-printable characters
are also considered terminators.  The space is needed for CI IO
redirection code and all other commands or programs that pass a byte
pointer to fopen and let it figure out where the POSIX name ends.
Again, there are no changes for MPE-only filenames.

  d) CI wildcarding characters (@, #, ?, [, ]) have precedence over the
same character being used literally in a POSIX filename.  Note the
shell sees nothing special about CI wildcard characters and supports
a backslash (\) escape character if you need to use shell metacharacters
in a filename.


The primary feedback I am looking for is do you immediately see potential
regression problems (ie. a program, script or job that you know won't
work correctly if this patch is installed).  I am also interested in
learning what concerns you may have with support for these extended POSIX
filenames.

Thanks in advance,
Jeff Vance, CSY

--

ATOM RSS1 RSS2