Craig A. Berry wrote:
At 11:56 PM -0400 6/3/06, John E. Malmberg wrote:
I have discovered that Perl on OpenVMS has components that expect
UNIX style shell macros in file specifications to be translated
intact through vmsify() and unixify().
What components of Perl, specifically?
RSYNC_ROOT:[PERL.lib.ExtUtils]MM_VMS.pm;1
$(ZIP) "$(ZIPFLAGS)" $(MMS$TARGET) [.$(DISTVNAME)...]*.*;
$(TAR) "$(TARFLAGS)" $(DISTVNAME).tar [.$(DISTVNAME)...]
$(SHAR) [.$(DISTVNAME)...]*.*; $(DISTVNAME).share
RSYNC_ROOT:[PERL.ext.DynaLoader]Makefile.PL;1
$(RM_RF) $(PERL_SRC)/$(OBJECT)
$(CP) $(OBJECT) $(PERL_SRC)/$(OBJECT)
The only unexpanded macro that can be safely "passed through to make
type programs" on VMS is one that you know will expand to a complete
(not partial) and syntactically valid VMS filespec, or one where you
have taken care to ensure that the components will assemble
themselves in a valid way after expansion. If you want to perform
conversions or concatenations or other operations on a string that is
a filespec with a macro embedded in it or a macro that has only part
of a filespec in it, your best bet is to expand the macros first.
That's why eliminate_macros() started out in MM_VMS rather than
File::Spec (probably before File::Spec even existed).
From mailing list conversations with Michael G. Schwern, it appears
that the only reason for eliminate_macros() is because Perl on OpenVMS
was storing environment variables in logical names instead of symbols.
Because MMS/MMK was not expanding those macros, an incorrect assumption
was made that macro handling in MMS/MMK was broken and
eliminate_macros() was created to hack around it.
This also created an undocumented requirement in unixify and vmsify to
understand and pass through the macros.
Before they had to handle extended file specifications, they would pass
these characters through by default, not by intention.
ODS-5 changes that.
I infer you have encountered a situation where the parentheses in a
macro reference have acquired caret escapes (possibly from a trip
through SYS$PARSE ?).
No. I discovered earlier that unixify() needed to pass through
$(macros), or MM related tests will fail. It was just recently that I
discovered that vmsify() should also probably be doing this.
In theory, the solution is simple: don't do
it, i.e., don't treat a macro as if it were a filespec because it
isn't. In practice, that advice may be hard to follow, depending on
the context, but without know the context, it's hard to say more.
I'm not sure what any of this has to do with what characters can be
part of a macro name, but you will find what the Open Group says
about that for UNIX make utilities here:
http://www.opengroup.org/onlinepubs/009695399/utilities/make.html#tag_04_84_13_04
The issue is that I am currently working on getting vmsify() to properly
handle ODS-5 names.
I assume you have access to the MMS documentation if that's the make
type utility you are concerned with.
If Perl on OpenVMS is converted so that MakeMaker is putting the
environment variables into DCL symbols, then the restriction would be
for what DCL will allow a symbol to have. In that case it would be
first character alphabetic, and the rest alphanumeric, with "$" and "_"
also allowed.
Of course if Perl on OpenVMS is running under the Bash shell, then the
specifications for what the OpenGroup should be used.
I have recoded my latest change to follow the Open Group says, and will
start a test shortly.
I still need a test example of a UNIX format file spec containing UTF-8
character sets that will allow me to verify that the two possible
OpenVMS format file specifications can result based on a feature
setting. That is: either []^xx^xx or []^Uxxxx . Where in the first
case, ^xx^xx is the ASCII-HEX representation of the UTF-8 in the UNIX
file specification, and ^Uxxxx is the ASCII-HEX representation of the
UCS-2 translation of the original UTF-8.
-John
[EMAIL PROTECTED]
Personal Opinion Only
