Re: PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursious behaviour.)
On 7/22/2014 7:13 AM, Craig A. Berry wrote: On Jul 21, 2014, at 7:41 PM, John E. Malmberg wb8...@qsl.net wrote: On 7/21/2014 7:06 PM, Craig A. Berry wrote: DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses. Well, I wouldn't think it did, but for some reason the two are wired together: The idea was that if you wanted UNIX filenames, you would also want UNIX exit statuses. I think I'm going to regard that as a bug and separate them. The logical GNV$UNIX_SHELL is defined when bash is running. It should be causing PERL_VMS_POSIX_EXIT to be in effect. That does not seem to be working on encompasserve.org. Regards, -John
Re: PERL_VMS_POSIX_EXIT (Re: Q: Can anyone explain this cursious behaviour.)
On 7/21/2014 7:06 PM, Craig A. Berry wrote:
On Jul 20, 2014, at 3:50 PM, John E. Malmberg wb8...@qsl.net wrote:
If you define PERL_VMS_POSIX_EXIT or DECC$FILENAME_UNIX_REPORT, it
is supposed to behave the way that you would normally expect.
That depends on what you normally expect. PERL_VMS_POSIX_EXIT should
more or less give you posixish behavior regarding exit codes. I can't
think of a good reason to enable it unless you are running under bash.
DECC$FILENAME_UNIX_REPORT has nothing at all to do with exit statuses.
The perlvms documentation needs to be updated.
http://perldoc.perl.org/perlvms.html
The PERL_VMS_POSIX_EXIT needed to be 1 to get it active. ENABLE did
not work. Perl VMS documentation only mentions ENABLE
Well it certainly does something:
$ define PERL_VMS_POSIX_EXIT 1 $ perl -e $! = 66; die; Died at -e
line 1. $ show symbol $status $STATUS == %X1035A212
66 is ENOTEMPTY. 66 might be embedded in that $STATUS value
somewhere, transmogrified by various kinds of masking and shifting,
but I'm late for dinner and have no time to debug it at the moment.
$ x = %x212/8
$ show sym x
X = 66 Hex = 0042 Octal = 102
BASH-4.2$ alias perl=/perl_root/perl.exe
BASH-4.2$ perl -e \
\$s=\$ENV{X} or die \no such environment variable: '\$!'\n\
no such environment variable: 'invalid argument'
BASH-4.2$ echo $?
22
BASH-4.2$ perl -e \
\$s='nosuchdir'; chdir \$s or die \Can't cd to \$s: '\$!'\n\
Can't cd to nosuchdir: 'no such file or directory'
BASH-4.2$ echo $?
2
BASH-4.2$ uname -a
OpenVMS EISNER 0 V8.3 AlphaServer_DS20_500_MHz Alpha Alpha HP/OpenVMS
Trying the DCL examples again:
$ perl -e $s='nosuchdir'; chdir $s or die Can't cd to $s: '$!, $^E'\n
Can't cd to nosuchdir: 'no such file or directory, %RMS-E-DNF, directory
not found'
$ show sym $status
$STATUS == %X1035A012
$ unix = %x12/8
$ show sym unix
UNIX = 2 Hex = 0002 Octal = 002
$ perl -e $s=$ENV{X} or die no such environment variable: '$!, $^E'\n
no such environment variable: 'invalid argument, %SYSTEM-F-NOLOGNAM, no
logical name match'
$ show sym $status
$STATUS == %X1035A0B2
$ unix = %x0b2/8
$ show sym unix
UNIX = 22 Hex = 0016 Octal = 026
This feature setting also allows perl to spawn child perls and capture
the original exit codes.
Regards,
-John
Re: Q: Can anyone explain this cursious behaviour.
On 7/20/2014 2:52 PM, John Dite wrote: 1.) A failed lookup in %ENV sets errno / vaxc$errno in our getenv implementation (specifically Perl_vmstrenv in [.vms]vms.c). This is normal and as it should be. 2.) die() (specifically Perl_my_failure_exit in perl.c) retrieves the most recent value of vaxc$errno and uses it as the VMS exit status. This is also normal behaviour. In the first example vaxc$errno was set to %RMS-E-DNF but $status is %SYSTEM-F-ABORT. That is the default behavior of Perl because older programs expect this behavior per documentation, all perl error exit codes were translated to 0x2c. http://perldoc.perl.org/perlvms.html If you define PERL_VMS_POSIX_EXIT or DECC$FILENAME_UNIX_REPORT, it is supposed to behave the way that you would normally expect. From a quick test on Encompasserve with PERL 5.18, that feature does not appear to be working. When that feature is working from DCL scripts or Bash you can recover the original Unix error code unless it is a VMS specific error. I do not know why the PERL_VMS_POSIX_EXIT feature does not appear to be working, I have not built/tested perl on VMS for a few years. In the second example, a usual, aka C, getenv() doesn't set errno. Why setting errno to EINVAL and vaxc$errno to NOLOGNAM is normal and as it should be for the VMS implementation is not obvious to me. Perl does not use getenv() for environment variables by default. It uses VMS system services to look up the current value. Anyway I'm off on vacation for the next 2 weeks, so don't expect any quick responses. Regards, -John wb8tyw@qsl.network
Re: rmdir('/unix_path/to/dir') not working with 5.18.1?
On 3/7/2014 8:18 AM, Craig A. Berry wrote: On Feb 26, 2014, at 11:35 PM, John E. Malmberg malmb...@encompasserve.org wrote: On 2/25/2014 7:02 PM, Craig A. Berry wrote: On Feb 24, 2014, at 11:33 PM, John E. Malmberg malmb...@encompasserve.org wrote: I can not seem to do a rmdir() of an absolute or relative Unix path with Perl 5.18.1. It works unless DECC$FILENAME_UNIX_REPORT is defined. That's not particularly well tested and you definitely found a bug. If that's defined, when rmdir calls the internal stat routine, which calls fileify, then 'abc/xyz' becomes 'abc/xyz.DIR;1'. If fileify is converting 'abc/xyz' to 'abc/xyz.DIR;1', that is a bug that will break a lot of stuff. With the DECC$EFS_CHARSET enabled, that should never happen anywhere. Not only should the ;1 not be present, the .DIR should not be present either. I think we've had this discussion before. Fileify really has to append the .DIR;1 because there are too many things, rmdir being one of them, that simply cannot operate on a directory spec but only on a directory file. That's really the point of fileify and we wouldn't call it if we didn't have to In a UNIX format filespecification, the .DIR or .DIR;1 is always a bug. Older CRTLs did that, but now you have to enable a DECC feature to get that mis-behaivor. With DECC$EFS_CHARSET disabled, this bug can be detected and compensated for, and since existing code expects the bug, for DECC$EFS_CHARSET disabled, fileify should continue to put the .DIR on for now. When I last updated fileify, I updated the documentation about this and that programs should not be written to depend on the .DIR being added because it is a bug, and they should not depend on the bug being present in future versions of Perl. With DECC$EFS_CHARSET enabled, fileify must not add a .DIR to a UNIX file path. If you do that, you can not have /file.dir/xyz as a legal file specification, and that shows up quite a bit. It seems that in build procedures foo/.dir/bar shows up a lot, so this bug is a big deal. It is one of the reason that I could not make EFS character set processing enabled by default. The ODS-2 to UNIX conversions were doing several things wrong, and programs were expecting that. But proper support of EFS character set prohibited doing the conversions wrong, so the perl self tests needed to know which mode to expect. Then stat converts it to VMS format and we get something like 'D0:[craig.TEST.abc]xyz.DIR^;1'. I tested this with decc$to_vms using the example in on-line help and it does not escape a semicolon that is part of a valid version spec. It does escape it if the version spec is not valid (or if the semicolon appears somewhere else in the name): $ mcr []to_vms abc/xyz.dat;32767 Translating: abc/xyz.dat;32767 file: [.ABC]XYZ.DAT;32767 1 files found $ mcr []to_vms abc/xyz.dat;123456789 Translating: abc/xyz.dat;123456789 file: [.ABC]XYZ.DAT^;123456789 1 files found The semicolon version delimiter is actually allowed by one of the Unix/Posix/Linux specifications that I read, but is rare in Unix because the shell uses it to terminate the command, and the file systems usually just treat it as part of the filename, not as a version. So it is not illegal for decc$to_vms to treat it as a version, but it is probably not the behavior that a ported program would expect. Neither DECC$EFS_CHARSET nor DECC$FILENAME_UNIX_REPORT has any impact on this. So I've changed vmsify in Perl to do exactly the same thing the CRTL does. Well, not exactly because the CRTL honors DECC$FILENAME_UNIX_NO_VERSION by escaping the semicolon even if the version spec is valid: Then Perl should also be using that feature. $ DEFINE DECC$FILENAME_UNIX_NO_VERSION 1 $ mcr []to_vms abc/xyz.dat;32767 Translating: abc/xyz.dat;32767 file: [.ABC]XYZ.DAT^;32767 1 files found I haven't (yet) made Perl do this. It wouldn't be hard to do, but I'm a little skeptical about trying to support the whole wilderness of feature logicals. It is something that IMHO is critical to add, and I encountered this in the test harness for GNU make and had to modify the code to work around it. There is almost no reason that most users of UNIX format file specifications would want DECC$FILENAME_UNIX_NO_VERSION enabled any time that DECC$FILENAME_REPORT_UNIX is enabled. And now that I have written this, my memory is coming back to me as to why I coded the conversion routines to always escape what looked like versions on UNIX. The DECC$FILENAME_UNIX_NO_VERSION used to only affect the readdir() function and no other conversions. So that mean that you could do a readdir() of [foo]abc^.bar.123 with report Unix and get abc.bar.123 as a filename, which when combined with the original path, resulted in foo/abc.bar.123. But because decc$to_vms was not honoring the DECC$FILENAME_UNIX_NO_VERSION settings in the older VMS versions, the resulting foo/abc.bar.123 could not be used as a path, unless
Re: rmdir('/unix_path/to/dir') not working with 5.18.1?
On 2/25/2014 7:02 PM, Craig A. Berry wrote: On Feb 24, 2014, at 11:33 PM, John E. Malmberg malmb...@encompasserve.org wrote: I can not seem to do a rmdir() of an absolute or relative Unix path with Perl 5.18.1. It works unless DECC$FILENAME_UNIX_REPORT is defined. That's not particularly well tested and you definitely found a bug. If that's defined, when rmdir calls the internal stat routine, which calls fileify, then 'abc/xyz' becomes 'abc/xyz.DIR;1'. If fileify is converting 'abc/xyz' to 'abc/xyz.DIR;1', that is a bug that will break a lot of stuff. With the DECC$EFS_CHARSET enabled, that should never happen anywhere. Not only should the ;1 not be present, the .DIR should not be present either. The .DIR should only be present with DECC$EFS_CHARSET disabled because that is what the older conversions expected, and on ODS-2 it could be removed on a reverse conversion. Then stat converts it to VMS format and we get something like 'D0:[craig.TEST.abc]xyz.DIR^;1'. abc/xyz.dir would be converted to [.abc]xyz^.dir or [.abc]xyz^.dir.dir. So we probably need to have fileify omit the version with unix report enabled. And the .DIR in UNIX paths, unless is foo/bar.dir = [.foo]bar^.dir.dir. Thanks, -John
rmdir('/unix_path/to/dir') not working with 5.18.1?
I am trying to get the GNU make 4.0.90 self tests run on VMS, and they
are written in perl.
I am making some progress, but have found some issues.
I can not seem to do a rmdir() of an absolute or relative Unix path with
Perl 5.18.1.
I have worked around the issue by replacing the rmdir() builtin method
with one that translates the filename to VMS format and then calls
unlink().
LION perl --version
This is perl 5, version 18, subversion 1 (v5.18.1) built for VMS_IA64
LION show log decc$*
(LNM$PROCESS_TABLE)
DECC$EFS_CASE_PRESERVE = ENABLE
DECC$EFS_CHARSET = ENABLE
DECC$FILENAME_UNIX_NOVERSION = ENABLE
DECC$FILENAME_UNIX_REPORT = ENABLE
DECC$READDIR_DROPDOTNOTYPE = ENABLE
LION show log perl_*
(LNM$PROCESS_TABLE)
PERL_ROOT = LION$DKA0:[SYS0.SYSCOMMON.perl-5_18.]
I also noticed that opendir('/search_list/directory') fails when
'directory' is only in the first member of the search list. I am not
sure what the issue there is. I think the solution for that will be
more complex.
I have worked around that issue by decoding the search list and
recreating the path to used for opendir.
Regards,
-John
Personal Opinion Only
Re: utils/perldoc.Com vs utils/perldoc
On 9/20/2013 8:05 PM, Craig A. Berry wrote: On Sep 20, 2013, at 6:01 PM, John E. Malmberg malmb...@encompasserve.org wrote: After all, if you are going to always use Perl to invoke it, why add the hack to make it work as a command file? Because you may not use Perl to invoke it. You may invoke it with DCL which will then invoke Perl. You can invoke it by putting it in the command tables, or by setting up a foreign command, or by placing it in a directory listed in DCL$PATH. Any and all of which can make perldoc run perl_root:[utils]perldoc.com as a command procedure (which then re-runs itself using Perl). That's about as close to having a shebang line as you're going to get on VMS. I would agree with all of that, except that this is what you get when you try running it as a command procedure: LION @perl_root:[utils]perldoc You called the perldoc command with a name that I didn't recognize. This might mean that someone is tricking you into running a program you don't intend to use, but it also might mean that you created your own link to perldoc. I think your program name is [perldoc.Com;1]. I'll allow this if the filename only has [a-zA-Z0-9._-]. at PERL_ROOT:[utils]perldoc.Com;1 line 11. I think that your name for perldoc is potentially unsafe, so I'm going to disallow it. I'd rather you be safe than sorry. If you intended to use the name I'm disallowing, please tell the maintainers about it. Write to: pod-perl...@rt.cpan.org at PERL_ROOT:[utils]perldoc.Com;1 line 11. And even more curious, why add a hack to make look like it should work as a command file with out actually making it work? Seems to be working just fine and as designed. Just printing an error message and exiting is how it was designed? Regards, -John
Re: utils/perldoc.Com vs utils/perldoc
On 9/21/2013 12:48 PM, Craig A. Berry wrote: On Sep 21, 2013, at 11:02 AM, John E. Malmberg malmb...@encompasserve.org wrote: On 9/20/2013 8:05 PM, Craig A. Berry wrote: On Sep 20, 2013, at 6:01 PM, John E. Malmberg malmb...@encompasserve.org wrote: After all, if you are going to always use Perl to invoke it, why add the hack to make it work as a command file? Because you may not use Perl to invoke it. You may invoke it with DCL which will then invoke Perl. You can invoke it by putting it in the command tables, or by setting up a foreign command, or by placing it in a directory listed in DCL$PATH. Any and all of which can make perldoc run perl_root:[utils]perldoc.com as a command procedure (which then re-runs itself using Perl). That's about as close to having a shebang line as you're going to get on VMS. I would agree with all of that, except that this is what you get when you try running it as a command procedure: LION @perl_root:[utils]perldoc You called the perldoc command with a name that I didn't recognize. Running it explicitly with @ syntax is not one of the options I mentioned. Using DCL$PATH gives the same result as using the @ syntax. Using a foreign command to run the perldoc.com is the same as using either DCL$PATH or the @ syntax. I have never seen command tables run a command script or know of a way to configure them to do so. I can not see any way to run perldoc.com with out passing it as a script to be run from Perl and work. And in that case, the shebang simulation is ignored. And even more curious, why add a hack to make look like it should work as a command file with out actually making it work? Seems to be working just fine and as designed. Just printing an error message and exiting is how it was designed? It was designed to be run as a command, not but running it with @. When you don't use it the way it was designed to work, it in fact (unsurprisingly) doesn't work. Most likely with enough effort it could be made to work that way as well, but it was never intended to, and I don't see the value of it. The wrapper that simulates the shebang only runs it in a way that produces an error message. I can not find any way to run it that takes advantage of the wrapper and results in useful output. All attempts to run perldoc.com as a command instead of as a perl script that I can find just result in it emitting an error message. The perldoc.com is not working the way that you describe because it is testing to see what the name of the script is. I do not know if that change happened after the shebang simulation was added. Since it has been run as a perl script by the foreign command, it has not been obvious that that running it standalone is not working. If the shebang simulation worked, then a simpler foreign command could be used. Regards, -John
Re: utils/perldoc.Com vs utils/perldoc
The perldoc command looks weird on VMS, and I do not know the origin of that convention. VMS does not support shebangs. Passing parameters on the command line to a program require that either the DCL shell command tables be modified to know about that command, or a foreign command to be created, or a DCL script be used. Now with perldoc.com and friends, a hack was done so that the resulting files are both a legal DCL command script and a legal Perl script. That is very useful It means that all we should have to do is set a foreign command to the perldoc.com and all should be well. But for some strange reason it is not, in this case, and I do not know why. When you run a script on VMS, you prefix it with a @ sign, and if you do not specify the .xxx extension, VMS adds a .com to the file. But you do not need an an extension. So to run perldoc.com on VMS you just do: @perl_root:[utils]perldoc.com -t If you do not quote the -t it gets uppercased by the DCL shell. But if you do the above, it fails because it sees it's argv[0] was perldoc.com and not perldoc. and refuses to work. Now that could not be too hard to fix. It should also work to create a new file name perldoc. The period is significant here in a new directory and then include the perldoc.com contents, and then copy the resulting file into the utils directory. [Oddity in VMS, you can not rename or copy perldoc.com to perldoc., VMS assumes that you want to keep the .com extension and will preserve it :-(] Then you could run it with the command below and it should just work. Note that the period is significant. @perl_root:[utils]perldoc. -t And then the foreign command would just be: perldoc :== @perlroot:[utils]perldoc. -t. So in theory there should not be a need to have the existing more complex foreign commands that are being set up. After all, if you are going to always use Perl to invoke it, why add the hack to make it work as a command file? And even more curious, why add a hack to make look like it should work as a command file with out actually making it work? Regards, -John
Re: utils/perldoc.Com vs utils/perldoc
On 9/19/2013 1:36 PM, Nicholas Clark wrote: If I delete the perldoc.com, I get this: $ perldoc Can't open perl script perl_root:[utils]perldoc.com: no such file or directory %SYSTEM-F-ABORT, abort (mail client may wrape the line) LION show sym perldoc PERLDOC == $PERL_ROOT:[00]PERL.EXE perl_root:[utils]perldoc.com -t The install/setup procedure creates a set of foreign commands similar to Bash aliases. Attempting to run perldoc.com by it self fails as it does not like its name. It looks like it is set up to only be run as a parameter to perl. The .com suffix was apparently added for some reason, but running the com procedure directly just says not to run it that way in so many words. So that is a bit confusing to me. To make things run under GNV Bash some helper scripts can be used, assuming that the logical name PERL_ROOT is set up. BASH-4.2$ cat /usr/bin/perl #! /bin/sh /perl_root/perl $* BASH-4.2$ cat /usr/bin/perldoc #! /bin/sh perl /perl_root/utils/perldoc.com -t $* BASH-4.2$ BASH-4.2$ perldoc -t Usage: perldoc.com [-hVriDtumFXlT] [-n nroffer_program] [-d output_filename] [-o output_format] [-M FormatterModule] [-w formatter_option:option_value] [-L translation_code] PageName|ModuleName|ProgramName Examples: perldoc.com -f PerlFunc perldoc.com -q FAQKeywords perldoc.com -v PerlVar The -h option prints more help. Also try perldoc.com perldoc to get acquainted with the system.[Perldoc v3.19] So, my question is, surely that file should be installed as utils/perldoc.COM not utils/perldoc? And if so, where in ExtUtils::MakeMaker does it need fixing? (Does anyone on VMS actually install modules from CPAN that have scripts?) I do not know. Regards, -John malmberg@encompasserve.organization Personal Opinion Only
Re: regression test filesystem assumptions
On 8/8/2013 2:31 AM, Nicholas Clark wrote: I think these changes are sane. Once upon a time, the CRTL did not support /dev/null as an alias for the native _NLA0:. I would have to build up a VMS 5.5-2 system on a SimH emulator to be sure of the behavior back at the beginning of the current CRTL image. There have been some features of the CRTL that have apparently been there since then, but only got documented recently. The /dev/null being used for NLA0: is one of them. Another is that /tmp is mapped to SYS$SCRATCH: if the logical name TMP: does not exist. Regards, -John
Re: regression test filesystem assumptions
On 8/7/2013 12:23 PM, Nicholas Clark wrote: I have this commit pushed to a smoke-me branch. It doesn't cause any test failures on the HP VMS testdrive system. Am I making bad assumptions? Specifically, is it filesystem dependant whether this code as-is will pass? open(H,'run/fresh_perl.t'); # must be in the 't' directory stat(H); print ok\n if (-e _ and -f _ and -r _); I infer that it must have failed 12 years ago, because the last line was corrected to print ok\n if (-e _ and -f _); But what changed to cause it to work now? Don't know why it ever failed on VMS unless there was a bug in the stat() routine for the version of VMS that the change was made on. Regards, -John
Re: 5.16.2 build
On 1/1/2013 4:51 PM, Craig A. Berry wrote: Apparently DECC$READDIR_DROPDOTNOTYPE enabled causes problems. We have that set at work for something else. I had to define it locally to disabled and the build completed. This doesn't surprise me at all. There is latent support that I suspect hasn't been tested much. Also note that whether you can build with it or not doesn't say much either way about whether you can run with it. Anyone interested can poke at what's there by doing: Several of the DECC$ logicals will probably interfere with build of Perl. I did my builds (a few years ago) with the DECC$ logical names settings off. I only turned them on for testing. Regards, -John malmb...@encompasserve.org Personal Opinion Only
Re: VMS::Time module
On 12/24/2012 4:19 PM, Thomas Pfau wrote:
I wrote a time module that interfaces to the VMS time system services -
$BINTIM, $ASCTIM, $GETTIM, and $NUMTIM. I also had a replacement routines
for $ASCTIM, $BINTIM and $GETTIM that could be used on non-VMS platforms.
Currently it accepts and returns VMS time buffers as 8 byte strings but I
was thinking of allowing numeric values to be passed if perl was built with
64 bit integer support. I could detect the input format by using
SvIOK/SvPOK. The problem I have is determining how the user wants the
information returned.
Can you use wantarray?
Current interface ($now and $bin are 8 byte strings containing the time):
$now = gettim();
$bin = bintim('01-jan-2010 12:00:00.00');
$asc = asctim($bin);
($year, $month, $day, $hr, $mn, $sc, $cc) = numtim($bin);
I'm thinking of using an optional additional argument on gettim and bintim
that would be written with the 8 byte string and have the routines return
the time as an integer if perl is built with 64 bit integers. I could try
to interface to the bigint module and return a bigint value if 64 bit
integers aren't available.
Would anyone find this useful? Any comments on the interface?
It might be useful. As I posted earlier, I am looking at what it would
take to implement a perl script that could be run detached to keep a VMS
directory synchronized with Dropbox.
While I have not yet started my investigation, I suspect that I will
need to convert time stamps from the DropBox server to that of the VMS
server. These time stamps might be in Windows format or Linux format,
so I would need a way to convert and compare the timestamps, hopefully
with the least loss of precision.
Regards,
-John
Personal Opinion Only
Re: perl 5.16.2 build problems
On 12/22/2012 8:07 AM, Craig A. Berry wrote: MCR SYS$DISK:[]generate_uudmap.exe uudmap.h bitcount.h mg_data.h Action did not update target BITCOUNT.H Action did not update target MG_DATA.H I'm not sure if this is a problem or not. Don't think so. MMS and MMK feel the need to tell you that they didn't do anything. It is a bug in MMS or MMK (possibly both) depending on where you saw it. The tool thinks it was told to create BITCOUNT.H and did not find it because bitcount.h was actually created. I reported a similar bug with library module handling to the current MMK maintainer, and he said he would look into it. I have not heard from him since. I just pulled down the latest DECSET ECO on Alpha, but have not tested it yet, and probably will not for a little bit. Regards, -John malmberg@encompasserve.organization Personal Opinion Only
BASH 4.2.39 available for OpenVMS.
Bash 4.2.39 is the current release and patch level of the GNU bash project and is now available for OpenVMS. Items of specific interest to the to the VMS Perl community are: Recent versions of Perl will go into a UNIX mode when run under Bash 4.2.39. This support of GNV is not 100 % complete at this time, but quite a few things are functional. The partial support has been in Perl since about Perl 5.12.x. Some portions may have been implemented earlier. To run Perl under GNV, place the following 2 line file in GNV$GNU:[usr.bin] Do not use any other hacks like copying portions of perl into the GNV$GNU: directory tree. $ type gnv$gnu:[usr.bin]perl. #! /bin/sh /perl_root/perl $* If you do not have privilege to copy files into gnv$gnu:[usr.bin], you can set up a concealed logical name old_gnu to point to the same concealed rooted directory as gnv$gnu: and a logical name new_gnu: to a directory that you have write access to. Use the job table to speed up subprocess creation. EAGLE show log gnv$gnu GNV$GNU = new_gnu: (LNM$JOB_821217C0) = old_gnu: 1 NEW_GNU = EAGLE$DQA0:[alpha_root.new_gnv.] (LNM$JOB_821217C0) 1 OLD_GNU = DISK$BIGDISK:[VMS$COMMON.GNV.] (LNM$JOB_821217C0) GNV$GNU = DISK$BIGDISK:[VMS$COMMON.GNV.] (LNM$SYSTEM_TABLE) Perl since 5.12.x also supports running scripts on VMS with shbangs in them, that is like #! /usr/bin/perl or #! /usr/sh in them. I have not yet attempted to run the Perl configure script under Bash 4.2.39. It is recommended that you read the release notes before installation or immediately after installation to make sure that the new version is used by GNV. You should install this kit on the same disk that GNV was installed on. If you have installed GNV which sets up a POSIX root, if you are not running the GNV startup procedure, the [vms$common.gnv.bin] directory will not be set up, and this will cause problems with installing other kits. Hopefully that issue will be fixed in a future GNV kit. If you installed the Bash 1.14.8 kit separate from GNV, it will have to be uninstalled before this kit can be installed because the producer is now GNV. Pre-built PCSI kits are at: ftp://encompasserve.org/gnv/axp0830/ Alpha 8.3 kits ftp://encompasserve.org/gnv/axp0840/ Alpha 8.4 kits ftp://encompasserve.org/gnv/i640840/ Itanium 8.4 kits Kits are planned to be in at the GNV project at sourceforge.net download section in the future. Regards, -John wb8tyw@qsl.network Personal Opinion Only
Looking for perl script synchronize dropbox.com with VMS
Before I go through the trouble of writing this, is anyone aware of a perl script that can be run on VMS using the DROPBOX.COM perl API to keep a VMS directory in synchronization? Currently I use NFS served disks on my local systems which are backed up / replicated to dropbox. What I am looking for is something that I can deploy on the HP Open Source cluster and some other public access VMS systems to run as either a batch job or a detached process that will keep a copy of my directory tree there up to date. Regards, -John wb8...@qsl.net Personal Opinion Only
Re: Parrot on VMS
On 10/26/2012 6:04 AM, Vorländer, Martin wrote: Parrot wants dynamic PMCs as dynamically loadable files, i.e. shared images. Building of these already works, but of course a lib$find_image_symbol won't find any symbols (as I don't yet have a SYMBOL_VECTOR). So I'm now diving into the process that converts a .PMC file into a .C file to see where I can get a list of symbols from to create an options file to link against. That seemed easier (and more portable) than pulling apart object files. If parrot has been ported to Microsoft Windows, there should be a procedure that extracts the symbol names for creating the DLLs. Regards, -John Personal Opinion Only
Re: scp to VMS
VMS Engineering has given us some feedback on SCP: The pscp program from Linux putty tools package will work with the VMS SCP program. I tested this and it work. This package does not appear to be available for Mac OS-X, so I do not have a solution there. Regards, -John
Re: scp to VMS (Re: mms case sensitivity build failures (was Re: HP hobbyist license))
On 5/22/2012 3:18 PM, Mark Berryman wrote: Instead, I simply built libssh2 on the unix box and used the example program sftp_write.c I just tried the sftp program in Scientific Linux 6.1 and it can upload files. The help for it says that it can recursively upload a directory. It looks like uploads either require interactive mode, or batch file mode. Downloads can be done with a simple command line. Or, use Multinet. It is just so much better. Not an option in this case, the remote system is maintained by HP. I also found that 'scp -2' is supposed to force SCP into using V2 of the protocol. No change seen in behavior from doing this. Regards, -John Personal Opinion Only
Re: scp to VMS (Re: mms case sensitivity build failures (was Re: HP hobbyist license))
On 5/19/2012 2:56 AM, Nicholas Clark wrote: Yes, this is the fun, and why it turns out that scp from VMS out to *nix works, but not the other way. Pretty much every *nix is using OpenSSH, whereas the VMS ssh is commercial ssh. OpenSSH has the original scp command, which I think is actually the source code of rcp with some edits. The rcp design is to have the same binary able to act as client and server. OpenSSH also provides sftp. snip I am passing on the following information to the Office of VMS Programs: It appears that the issue with SCP into TCPIP 5.7, is that it is trying to run the program TCPIP$SSH_SCP1.EXE, and generates that error message when it fails. Which means that either that image is missing from the kit or it was never built. From trying to substitute tcpip$ssh_scp2.exe for it, I get a different error about unexpected new-line. This means that if the issue is more complicated than just the image accidentally left out of the TCPIP KIT, we could probably substitute an open source program by assigning the logical name TCPIP$SSH_SCP1 to it. The OpenSSH project contains an SCP1 program that will probably work. Regards, -John
Re: scp to VMS
I have submitted a list of issues about the HP OpenSource cluster that Nicholas posted, and a few others that I noticed to the Office of OpenVMS programs e-mail address and a received a reply that they will be looking at getting these resolved. Regards, -John Personal Opinion Only
Re: HP hobbyist license
On 5/15/2012 12:52 PM, Carl Friedberg wrote: At this very moment, all 3 of my VMS servers are unreachable, but normally they are accessible. I have two (pretty ancient) AlphaServer 800's, single 500mhz processor, 2 Gb memory, running recent VMS with hobbyist licenses. I also have an Itanium RX2600 dual-core box running OpenVMS 8.4 (similar to the one Craig uses, I suspect). All of these are available to perl developers. Send me an e-mail and I will set up an account for you. The problem is that as Nicholas Clark is being paid for this work, it may not be legal to do it on a system licensed with Hobby licenses. As part of an offline conversation, Nicholas Clark is getting access to the HP Open Source cluster, which should cover the licensing issue. Regards, -John
Re: RFC: UTF-8 perl (not Perl) source code
On 8/8/2011 5:25 AM, Nicholas Clark wrote: On Sun, Aug 07, 2011 at 01:44:23PM -0700, Father Chrysostomos wrote: If I change the quotes at the top of the *.c files in the perl source code to use UTF-8 instead of Latin-1, would anyone object? I have my text editor set to use UTF-8 by default, so it complains whenever I open those files. I have a vague memory (possibly wrong) that there was a VMS editor that choked (in some fashion) on UTF-8. [And if so, I guess because it assumes that source code is ISO-8859-1, and no C1 control characters] The VMS DECTerm terminal emulator (X11 based) locks up from the output of the unicode tests while running Perl. VMS basically only supports ASCII and the 8 bit ISO character sets for terminal output for the non-internationalized versions. I have not worked with the internationalized variants to know if they have the same issues. -John malmberg@encompasserve.organization Personal Opinion Only
Re: problem building perl 5.10.1
Fabio Ciampi wrote: Hi I'm a newbie of VMS. I've tried to build perl 5.10.1 on my IA64 Welcome to VMS. I see a couple of newbie mistakes below, but they probably are not causing the issues that you are seeing, just additional issues. And these are somethings that people with experience should have learned but many have not. Operating System (Version V8.3-1H1) with ODS5 disks. I have MadGoat Make Utility V4.1 and compiler HP C V7.2-001. I gave the following commands after download perl sources and unpacked them: set security/protection=(o:rwed) perl-5^.10^.1.DIR;1 rename perl-5^.10^.1.DIR perl-5_10_1.DIR @configure -des -Dprefix=DATE$MSA1:[PERL-5_10_1.] I have not used the -Dprefix. On VMS, I use logical names to determine which version of an application to run. Perl uses the logical name PERL_ROOT, regardless of what prefix that you assign. Newbie note 1: In general in managing VMS, physical device names should generally be referenced only in the startup procedures where logical names are mapped to them, and in utilities like backup or defragmenters that need to specifically operate on physical devices. Any applications other than the above that require a physical device name instead of a logical name is broken, and not properly written for VMS. Some applications have broken configuration routines that put physical device names in configuration files instead of logical names. In most cases, I have found that manually fixing the configuration files makes the application more maintainable. If I move the the application or its data to a new physical disk, all I should have to do is change how the logical names are mapped. I should never have to reconfigure an application for that. And I should never need to notify an end user when I change what physical devices that are being used by the computer or one of their applications. VMS uses logical names for things that Unix uses symbolic links for, but logical names are far more powerful and flexible. mmk mmk test The mmk process works (I only have some Warning: long symbol). During mmk test I saw some tests failed: t/op/exec.FAILED at test 16 ext/Compress-Raw-Bzip2/t/01bzip2..FAILED--expected 157 tests, saw 10 ext/Compress-Raw-Bzip2/t/09limitoutputFAILED--expected 88 tests, saw 5 ext/IO-Compress/t/001bzip2FAILED at test 58 ext/IO-Compress/t/006zip..FAILED--expected 77 tests, saw 17 Perl is sensitive to the logical name BIN, and foreign commands for ZIP and BZIP2 among others. Older versions of the GNV product would incorrectly assign the logical name BIN in the system table, and many people will put in symbols for ZIP and BZIP2 in the SYLOGIN.COM or LOGIN.COM. Other applications may set the BIN logical name and leave it behind. If some of the tests find a ZIP or BZIP executable, they will try to use it just like a UNIX utility and may expect that they are running it under the Bash shell. Perl also now supports the DECC$* feature logicals at run time. Not all combinations have been tested, and some combinations will cause tests to fail because they change the behavior in ways that the tests do not yet expect. It is also possible that running on your environment may need some more quota for a resource than the build procedure knows to test for. For building and the initial testing of Perl, make sure that all the DECC$ feature logicals are set to their default. Then read the two VMS specific text files in Perl for their usage. Newbie note 2: [DIR$UTIL.PERL_5-010.PERL-5_10_1]PERL.EXE;1 The use of '$' in logical names, filenames, directories, and symbols is reserved to HP/VMS and registered third party usage. It should not be used in names that you make up for your own use unless directed to by the either the VMS or third party that has registered the prefix for that name. This is a long standing rule in VMS, but it used to be easier to find in the documentation. This prevents your names and names from HP or layered products from having a conflict. There is documentation in the VMS doc set on getting those names registered by application developers. With all the possibilities out there, the odds of a conflict of making up your own names with $ in them are low, but it is not zero. Some layered products use undocumented prefixed logical names to enable debugging or other diagnostic procedures. In addition, some TCPIP products use the $ in filenames to do encoding of case changes or other special characters in NFS exports and mounted disks. -John wb8...@qsl.network Personal Opinion Only
Re: Perl 5.12.1 build report
On 6/24/2010 2:03 PM, Mark Berryman wrote: On Jun 24, 2010, at 12:08 PM, Craig A. Berry wrote: 4. Too many extensions like to use labels that differ only in case or reference external libraries that are built with /names=(as_is,short). By editing 3 include files in Perl, extern.h, perl.h, and xsub.h in PERL_ROOT:[.LIB.VMS_arch.5_12_1.CORE], to set the NAMES pragma to uppercase at the beginning of the file and restore it at the end, I am able to modify the generated DESCRIP.MMS file of the extension being built to include the names=(as_is,short) switch and build the extension without difficulty. I believe this would be worth doing as part of the standard installation. It would also be nice if there were an option to add this switch into the generated DESCRIP.MMS automatically. You can get /NAMES=AS_IS by configuring the Perl build with: $ @configure -Dbe_case_sensitive=Y -des Unfortunately pragma names are not standardized. While they may end up meaning the same thing on different compilers, nothing enforces that, so pragmas must be wrapped with a test for the compilers that they are known to be valid on that may be used for the compilation. It gets messy fast. I tried this once. The build fails to even build miniperl. Here I can reproduce this fairly quickly... Link /NoTrace/NoMap/Trace/Exe=MINIPERL.EXE miniperlmain.obj, libperlmini.olb/Library/Include=globals ,[]crtl.opt/Options %ILINK-W-NOSUCHMOD, module GLOBALS not found in library USERS:[BERRYMAN.PERL-5_12_1]LIBPERLMINI.OLB;1 %ILINK-W-NUDFSYMS, 8 undefined symbols: %ILINK-I-UDFSYM,lib$find_image_symbol %ILINK-I-UDFSYM,lib$initialize %ILINK-I-UDFSYM,lib$rename_file %ILINK-I-UDFSYM,sys$filescan %ILINK-I-UDFSYM,sys$get_security %ILINK-I-UDFSYM,sys$getdviw %ILINK-I-UDFSYM,sys$set_security %ILINK-I-UDFSYM,sys$sigprc Those undefined symbols should be easy to fix, they just need to be declared in upper case in the source file. I am trying to remember if I submitted a patch to do that before. Unfortunately the system header files for defining those routines is generated by a program that has not been updated to properly generate function prototypes from the source file it uses. That is why I never use that file, and instead manually prototype the system services. The proper prototypes make several common programming errors to be detected by the compiler. snip All this does is tell MMS that, when processing a .C file into a .OBJ file, check to see if the filename is uppercase. If not, rename it so it is. The syntax at COMPLETE_APPLICATION tells MMS to compare the module in the library to the source and rebuild it if it has changed but it only works if the module names in the library are all uppercase (otherwise it aborts with an action did not update target error). Would this help make Perl any more independent of the type of build disk being used? We need a solution for building on ODS-5 that results in the files and directories having the same case as on a Unix system. This stopped me from testing with Perl set for exact case filenames. However, I have not found out how to get MMS to accept a lower case module name into a library. It seems to be expecting the module name to be uppercase. So putting in a rename in MMS files created on ODS-5 volumes may be needed. I thought that MMK did not have this issue. I am currently using DEC MMS to build GNV bash and I ran into that issue. The mkbuiltins utility is only creating lowercase filenames, and I do not plan to look at changing it. I ended up setting the following rule: # MMS requires that the generated name be in upper case to generate an # upper case module name for the librarian. .def.c @ mkbuiltins :== $prj_root:[]mkbuiltins.exe $ set def prj_root:[.builtins] $ source = f$parse($(MMS$SOURCE),,,NAME) $ source_u = f$edit(source, UPCASE) $ mkbuiltins -D ./builtins/ 'source'.DEF $ if f$getsyi(ARCH_TYPE) .ne. 1 then set proc/parse_style=extended $ if f$getsyi(ARCH_TYPE) .ne. 1 then rename 'source'.C 'source_u'.C $ set def prj_root:[-] So what ever we do to make it build, we will need to do something to make sure that all files and directories for running the self tests end up in the correct case on ODS-5 volumes. xsubpp should do its own name shortening, but that can cause trouble with external libraries. I'd consider making /NAMES=(AS_IS,SHORTENED) the default for 5.14.0, but need to give some thought to what will break. xsubpp seems to shorten names declared in the XS file but it doesn't seem to touch names that are simply references to something external. In the list of extensions I gave, there are several instances where some names are shortened and others are not. This is probably a good thing because I don't know of anything else that uses the same shortening algorithm used in Perl. By using /names=(as_is,short) in the extension build
Re: Problem with VMS Carriage return carriage control files in 5.10 and 5.12
martin.zin...@deutsche-boerse.com wrote: Hello Colleagues, I am currently trying to drag our development team kicking and screaming into the century of the fruitbat, but what looks like a bug in 5.10.1 and 5.12.0 is a stumbling block. Problem description: If you open a text file with Carriage return carriage control for output (based off an existing file) and populate the new file with longer records, at some point gratuitous line breaks are added to the file. This does not happen with either Perl 5.8.0 on Alpha, nor Perl 5.8.5 on Itanium (in that case the hp build). It does happen with both 5.10.1 and 5.12.0 on Itanium. The bug should be present in the older 5.8.0, it just may be something is causing you to miss it. The issue is that the pipe emulation code in perl adds extra new-lines to output from subprocesses. The size of the mailbox buffer may have something to do with when the new-line is added. It may be that something changed there. In PERLVMS.POD, it documents that PERL_MBX_SIZE controls this with a default of 512 bytes. I do not recall any changes to that code since I started working with Perl internals, and that was with perl 5.8.6. The only changes that I can recall is that the size of the command buffer and parameters was adjusted to match what VMS supports, and there were some improvements in launching subcommands. But obviously something is different between the two versions. Regards, -John wb8...@qsl.net Personal Opinion Only
Re: VMS and Unix pathnames
Nicholas Clark wrote: Currently the core uses File::Spec inside the test running script, t/TEST, that VMS uses. If I understand perlvms.pod correctly, perl on VMS can understand Unix-like pathnames directly. I'd like to remove File::Spec from t/TEST, as it's something complex run too early in testing. Would the appended change work on VMS? It assumes that As the current t/TEST is used now, I think it is passed the starting file specification in VMS format. So on VMS you still need a VMS::Filespec::unixify to convert the input path parameter(s) to the test. 1: relative pathnames, Unix style, work Those mostly work. Testing would be needed to verify that these work for the pathnames that show up for t/TEST. 2: readdir returns '.', '..' and directories in Unix format I think we would need to verify that also. I have been mostly focused on making Perl work with Unix file specifications using the Extended Character set. In the default/traditional mode of Perl on VMS, it was deemed acceptable for routines to return VMS format paths on output even when given Unix format paths on input. With the new Unix compatible mode, that should not happen. Is that assuming to much? Would a subdirectory foo actually be returned as foo. or foo.DIR? In the default/traditional mode of Perl on VMS, subdirectory foo will be returned as foo.dir when readdir() or glob operation is given a UNIX format path. It is a bug that we can not remove because there may be existing perl modules that depend on it being present. Also in the default/traditional mode of Perl on VMS, file specifications are converted to lower case. The older file system on VMS only stores file names in uppercase, and code in VMS.c would convert them to lowercase for better Unix compatibility. When Perl on VMS is operating in the Extended Character Set mode with case preservered, then subdirectory foo will return foo, and FOOBAR will be returned as FOOBAR, provided that the Perl directory is on a disk with the newer file system and that the directory was created with the correct case. I have noticed that some of the files and directories created by the Perl build procedure on VMS are in the wrong case. VMS by default does not pay attention to the case when looking up a file, but if something is doing a directory lookup, they will get either the old behavior of all lowercase names, or the new behavior of exactly the case that is on the disk. When I am doing the tests, I set the mode that Perl is in before running all the tests. (I've also attached the entire file TEST, if anyone wants to try, and doesn't have a patch tool on VMS. You can get a snapshot of blead from http://perl5.git.perl.org/perl.git/snapshot/HEAD.tar.gz ) No attachment showed up. I will try to do a build of blead sometime early this week to see how it works on VMS/Alpha. I'm not subscribed to the vmsperl list, so please Cc: me on responses. Nicholas Clark -John wb8...@qsl.net Personal Opinion Only
Re: VMS and Unix pathnames
Nicholas Clark wrote: On Mon, Aug 24, 2009 at 08:40:44AM -0500, John E. Malmberg wrote: Nicholas Clark wrote: Currently the core uses File::Spec inside the test running script, t/TEST, that VMS uses. If I understand perlvms.pod correctly, perl on VMS can understand Unix-like pathnames directly. I'd like to remove File::Spec from t/TEST, as it's something complex run too early in testing. Would the appended change work on VMS? It assumes that As the current t/TEST is used now, I think it is passed the starting file specification in VMS format. So on VMS you still need a VMS::Filespec::unixify to convert the input path parameter(s) to the test. If I understand vms/test.com enough: $ If PERL_TEST_DRIVER .eqs. minitest $ Then $ MCR Sys$Disk:[]Perl'exe' TEST. -minitest base/*.t comp/*.t cmd/*.t run/*.t io/*.t op/*.t uni/*.t $ Else $ MCR Sys$Disk:[]Perl'exe' -I[-.lib] 'PERL_TEST_DRIVER' ''p3' ''p4' ''p5' ''p6' ''p7' $ EndIf and vms/descrip_mms.template test : all [.t.lib]vmsfspec.t [.t.lib]vms_dclsym.t [.t.lib]vms_stdio.t unpack_files @ PERL_TEST_DRIVER == TEST. - @[.vms]test.com $(E) $(__DEBUG__) @ $(MINIPERL) -e print Ran tests; [.t]rantests. then under minitest, it's being passed Unix-style globs, and under test, nothing. So it is already expecting Unix-style names. vms/test.com is also run manually and when that is done, it is generally passed a VMS style path name, which it would have a difficult time to translate to a Unix path name to pass to t/TEST. -John wb8...@qsl.net Personal Opinion Only
Re: smoking VMS (was Re: maint-5.10 status on VMS)
Craig A. Berry wrote: On Jul 24, 2009, at 3:40 PM, Nicholas Clark wrote: On Fri, Jul 24, 2009 at 03:35:33PM -0500, Craig A. Berry wrote: I've finally got Test::Smoke mostly working on VMS except for my local mail configuration, thus the manual attachment here. It shows the Ooh. ooh. ooh. ooh. What will it take to get the mail bit sorted, so that it can run automatically? And run automatically on blead too? I've run it successfully with both blead and maint, and I've implemented support in Test::Smoke for the native VMS mail utility and successfully sent myself smoke reports with it. One approach to getting mail to places it needs to go would be to subscribe to one or another perl.org mailing list with the account on each machine that will be generating smoke reports (these are on my home network and I don't normally use them for e-mail). Another approach would be to add support to Test::Smoke to use MIME::Lite's authentication features and send via an external smtp server, though that would involve leaving a password sitting around in clear text. Bram has now suggested a third possibility, which is interesting. I will now go and read the Test::Smoke FAQ and find out what I'm supposed to be doing :-). Oh, and you used the word automatically, which still needs some work. I'm currently running rsync on Mac OS X in order to get the .patch file so we know what we're smoking, then generating a zipball and moving it to ~/Sites, then kicking off a job on the VMS side that uses curl to pull it across and run the smoke test. When a tuit or two present themselves, there are lots of different approaches to coordinating and automating all of this. I can supply you with a GIT program that can clone a repository. I can not get the other functions working for a while due to limitations in the GNV ports of several utilities and some other problems. If you (or anyone else) wishes to pursue that, drop a mail on the vms-perl list and I will respond with the details. I do not know if the clone function can pull down a specific branch. It is also pretty slow. It takes at least 1/2 for the git clone to pull down Perl on my DS-10. -John wb8...@qsl.net Personal Opinion Only
Re: Perl 5.10.1 release notes help needed
Craig A. Berry wrote: It's looking like we'll get a release candidate for Perl 5.10.1 in the next week or two. Indications are it will be the best ever Perl on VMS release, but it would be helpful if the so-called perldelta, the changes since the previous release, could be updated for accuracy and completeness. What's in there so far is below. I will see what I can come up with, but people who know things (especially John M.), should give a holler with relevant details. An update to the pod is in order for the PERL_VMS_POSIX_EXIT logical name. That should help you with what to put in the delta file. I forgot to indicate in the file that the DECC$FILENAME_UNIX_REPORT feature also activates the PERL_VMS_POSIX_EXIT mode. The support for UNIX filenames when using the DECC$FILENAME_UNIX_REPORT and DECC$EFS_CHARSET has been greatly improved. Only a few of the dual life modules do not have support. -John wb8...@qsl.net Personal Opinion Only --- /rsync_root/perl/pod/perlvms.podMon Apr 20 04:03:09 2009 +++ pod/perlvms.pod Wed Jul 15 21:13:08 2009 @@ -1167,16 +1167,16 @@ SS$_NORMAL, and setting C$? to a non-zero value results in the generic failure status SS$_ABORT. See also Lperlport/exit. -With the future POSIX_EXIT mode set, setting C$? will cause the -new value to also be encoded into C$^E so that the either the -original parent or child exit status values of 0 to 255 -can be automatically recovered by C programs expecting _POSIX_EXIT -behavior. If both a parent and a child exit value are non-zero, then it -will be assumed that this is actually a VMS native status value to -be passed through. The special value of 0x is almost a NOOP as -it will cause the current native VMS status in the C library to -become the current native Perl VMS status, and is handled this way -as consequence of it known to not be a valid native VMS status value. +With the CPERL_VMS_POSIX_EXIT logical name defined as ENABLE, +setting C$? will cause the new value to also be encoded into C$^E +so that the either the original parent or child exit status values o + 0 to 255 can be automatically recovered by C programs expecting +_POSIX_EXIT behavior. If both a parent and a child exit value are +non-zero, then it will be assumed that this is actually a VMS native +status value to be passed through. The special value of 0x is +almost a NOOP as it will cause the current native VMS status in the +C library to become the current native Perl VMS status, and is handled +this way as a it is known to not be a valid native VMS status value. It is recommend that only values in range of normal UNIX parent or child status numbers, 0 to 255 are used. @@ -1186,10 +1186,15 @@ non-zero values to SS$_ABORT when setting C$? in an END block (but zero will still be converted to SS$_NORMAL). -Do not use the pragma Cuse vmsish 'status' with the future -POSIX_EXIT mode, as they are at times requesting conflicting -actions and the consequence of ignoring this advice will be -undefined to allow future improvements in the POSIX exit handling. +Do not use the pragma Cuse vmsish 'status' with CPERL_VMS_POSIX_EXIT +enabled, as they are at times requesting conflicting actions and the +consequence of ignoring this advice will be undefined to allow future +improvements in the POSIX exit handling. + +In general, with the PERL_VMS_POSIX_EXIT enabled, more detailed information +will be availble in the exit status for DCL scripts or other native VMS tools, +and will give the expected information for Posix programs. It has not been +made the default for backward compatibility. =item $|
Re: Perl 5.10.1 release notes help needed
Craig A. Berry wrote: On Jul 15, 2009, at 9:45 PM, John E. Malmberg wrote: An update to the pod is in order for the PERL_VMS_POSIX_EXIT logical name. That should help you with what to put in the delta file. Thanks, John, this is in blead at http://perl5.git.perl.org/perl.git/commitdiff/d9ac7b6. What about the GNV$UNIX_SHELL logical? Should we leave it undocumented or should we document it and say it's subject to change if a supported mechanism for detecting the GNV bash shell becomes available? I do not know when the GNV bash/make utilities will start setting that logical name. Until we can get some testing done with it, either we should leave it undocumented or document it as experimental. -John wb8...@qsl.net Personal Opinion Only
Some progress on git
I seem to have made some progress with GIT. I have it building now, but I am confused as the program execs image names slightly different than the ones that the build procedure creates and installed. If I rename the module to match the name that git uses, that seems to work. The only thing I have tried so far is the clone function. EAGLE git clone git://perl5.git.perl.org/perl.git Initialized empty Git repository in /GIT_ROOT/base/perl/.git/ remote: Counting objects: 267296, done. remote: Compressing objects: 100% (59781/59781), done. Receiving objects: 99% (266984/267296), 71.72 MiB | 230 KiB/s Receiving objects: 100% (267296/267296), 71.83 MiB | 136 KiB/s, done. Resolving deltas: 100% (208264/208264), done. Checking out files: 100% (4616/4616), done. EAGLE dir git_root:[base.perl...]/grand Grand total of 682 directories, 5325 files. EAGLE The resulting tree looks complete, but is missing the .patch file that I get with the rsync download. I have not yet worked on getting the daemon running or doing the make check step to do more verification, so this is a bit preliminary. -John wb8...@qsl.net Personal Opinion Only
Re: [blead 2009-05-29.22:08:17] vms.c EFS logical name fix.
John E. Malmberg wrote: Here is the latest attempt. Still not fully tested. And the results are that with this new change, I am getting failures in the UNIX mode with: lib/File/Compare.t, lib/File/Spec/t/Crossplatform.t, lib/File/Temp/t/object.t, lib/Module/Build/t/compat.t, lib/vmsish.t Some of the above failures may be because I did not define SYS$SCRATCH or /tmp to be on an ODS-5 volume, so it may not be as bad as what it looks. I am also running the makemaker code with out the Unix compatibility changes, as Michael has not integrated them yet, and those are failing, along with the new lib/Test/Simple/t/exit.t In VMS/EFS mode, 52 tests are failing that do not fail in the default VMS mode. I really am short of cycles right now, so I think we may have to work on getting better support for VMS/EFS for Perl next, and just document that while the UNIX mode is working reasonably well, there are known issues with EFS / VMS mode. We really need to get some sort of logical name support that we can count on being bundled with Perl on VMS. We really could use more volunteers to help get the EFS mode working. Debugging Perl is much easier now with the support for the forked debugger on VMS, so I can help with people who want learn how to troubleshoot these issues. Regards, -John wb8...@qsl.network Personal Opinion Only
Re: [blead 2009-05-29.22:08:17] vms.c EFS logical name fix.
Thomas Pfau wrote:
John E. Malmberg wrote:
We really need to get some sort of logical name support that we can
count on being bundled with Perl on VMS.
My VMS::Logical module appears to work. I don't think I ever uploaded it
to CPAN but I could do that.
http://axp1.nbpfaus.net/~pfau/perl/VMS-LOGICAL-0_3.ZIP
That is a start, but we need it as part of the base Perl distribution on
VMS.
The big issue is the dual life modules that like PathTools that really
need to be aware of VMS logical names and the mode that the C Runtime is in.
I put in checks to have a VMS::Feature module be used if present, and
a fallback to use $ENV{} to lookup logical names.
The same type of checks will be needed for things that need to look up
logical names.
Michael Schwern does not like those hacks and would like to see
something better, so currently he has not included the Unix
compatibility mode into the ExtUtils modules that he maintains.
So we need to see what we can do to come up with a method that meets his
approval.
A lot of investigation and coding and debugging is needed.
If you can use NFS to share a disk with a Linux system, it is easy to
set up so rsync on or git on Linux can be used to keep the current blead
perl up to date on VMS.
Regards,
-John
wb8...@qsl.net
Personal Opinion Only
Re: getting new VMS extensions into Perl (was Re: [blead 2009-05-29.22:08:17] vms.c EFS logical name fix.)
Craig A. Berry wrote: On Jun 10, 2009, at 7:29 PM, John E. Malmberg wrote: There is considerable interest currently in removing extensions from the core and reluctance to add them. This derives from somewhat of a binge in adding new extensions in recent years that add to the maintenance burden of the core developers at a time when the core developers have become spread rather thin. The basic criteria now are that to be in core an extension should be essential for building Perl and/or installing other extensions. Arguably VMS::Feature and VMS::Logical could meet these criteria since they expose aspects of the environment that are of interest when building things. But as far as anyone who would have any say in incorporating them is concerned, they don't exist because they are not on CPAN. Get them on CPAN and other possibilities arise, though probably not before Perl 5.12.0. If we can get them into CPAN, would it be acceptable to make them a requirement for other CPAN modules to use them just on the VMS platform? Regards, -John wb8...@qsl.net Personal Opinion Only
Re: [blead 2009-05-29.22:08:17] vms.c EFS logical name fix.
John E. Malmberg wrote:
Craig A. Berry wrote:
I went back to my original test case (not the narrower one you ended
up fixing) and it looks like we are half-way there. If both
DECC$EFS_CHARSET and DECC$FILENAME_UNIX_REPORT are defined, this works:
$ perl -MFile::Spec::Functions -e print
catfile(File::Spec-tmpdir(), 'bar');
/sys$scratch/bar
but if only DECC$EFS_CHARSET is defined, it doesn't:
$ perl -MFile::Spec::Functions -e print
catfile(File::Spec-tmpdir(), 'bar');
[.sys$scratch:]bar
The attached patch has not been run through a full test run yet.
The problem was that catfile was expecting that the path components were
either contained VMS directory delimiters or were bare words.
The earlier part of the code detected the trailing : so knew to treat
the path a VMS.
This patch allows a path ending with a : to be treated as a VMS
directory path.
This patch is better, but still not fully tested.
I did not run a comprehensive test of EFS mode with out Unix report also
on before, and this is exposing some dragons that are going to take some
time to slay.
There are a number of tests and modules that will need to be adjusted to
handle VMS EFS charsets that I have found.
testp2pt.pl needs a patch as it is trying to do catfile() on directories.
cwd.t is creating an illegal symbolic link unless it is in UNIX mode, so
it does not get resolved.
ext/File-Glob/t/Basic.t is trying to compare the results of a directory
in UNIX syntax with one in VMS syntax. With EFS on, VMS names with out
extensions have the trailing periods present.
There are a few other failures that I do not understand yet.
Regards,
-John
wb8...@qsl.net
Personal Opinion Only
--- /rsync_root/perl/lib/File/Spec/VMS.pm Sun May 10 04:02:09 2009
+++ lib/File/Spec/VMS.pmMon Jun 8 01:19:01 2009
@@ -195,6 +195,32 @@
if ($efs) {
# Extended character set in use, go into DWIM mode.
+if ($path =~ /:$/) {
+# We have a problem. If we do a syntax only conversion
+# we can break existing code that does not understand how
+# logical names and directories can be combined.
+my $test_path = $path;
+my $i = 0;
+while ($i 10) {
+# We need to do a logical name check, but we do not have
+# logical name services in perl. So we need to $ENV until
+# that can be remedied.
+$test_path =~ s/:$//;
+my $test_trnlnm = $ENV{$test_path};
+last unless defined $test_trnlnm;
+if ($test_trnlnm =~ /\.[\]]$/) {
+# A rooted logical name, same as device so use as is.
+last;
+}
+if ($test_trnlnm =~ /[\]]$/) {
+# Found a directory, use this instead of the path
+$path = $test_trnlnm;
+last;
+}
+$test_path = $test_trnlnm;
+$i++;
+};
+}
# Now we need to identify what the directory is in
# of the specification in order to merge them.
@@ -204,6 +230,7 @@
my $path_vms = 0;
$path_vms = 1 if ($path =~ m#[\[\]]#);
$path_vms = 1 if ($path =~ /^--?$/);
+$path_vms = 1 if ($path =~ /:$/);
my $dir_unix = 0;
$dir_unix = 1 if ($dir =~ m#/#);
$dir_unix = 1 if ($dir =~ /^\.\.?$/);
@@ -237,8 +264,10 @@
#with posible instead of [.
# Normalize the brackets
# Fixme - need to not switch when preceded by ^.
-$path =~ s//\[/g;
-$path =~ s//\]/g;
+if ($path !~ /:$/) {
+$path =~ s//\[/g;
+$path =~ s//\]/g;
+}
$dir =~ s//\[/g;
$dir =~ s//\]/g;
@@ -251,6 +280,7 @@
#If path is foo, it needs to be converted to [.foo]
# Fix up a bare path name.
+my $is_abs_path = 0;
unless ($path_vms) {
$path =~ s/\.dir\Z(?!\n)//i;
if (($path ne '') ($path !~ /^-/)) {
@@ -258,6 +288,7 @@
$path = '[.' . $path;
} else {
# Just start a directory.
+$is_abs_path = 1 if $path eq '';
$path = '[' . $path;
}
} else {
@@ -276,16 +307,25 @@
$dir =~ s/\]$//;
}
-#strip off the leading dot if present.
-$dir =~ s/^\.//;
-
# Now put the specifications together.
if ($dir ne '') {
-# Add
Re: [blead 2009-05-29.22:08:17] vms.c EFS logical name fix.
Craig A. Berry wrote:
On Jun 8, 2009, at 1:42 AM, John E. Malmberg wrote:
Below inline:
John E. Malmberg wrote:
Craig A. Berry wrote:
I went back to my original test case (not the narrower one you ended
up fixing) and it looks like we are half-way there. If both
DECC$EFS_CHARSET and DECC$FILENAME_UNIX_REPORT are defined, this works:
$ perl -MFile::Spec::Functions -e print
catfile(File::Spec-tmpdir(), 'bar');
/sys$scratch/bar
but if only DECC$EFS_CHARSET is defined, it doesn't:
$ perl -MFile::Spec::Functions -e print
catfile(File::Spec-tmpdir(), 'bar');
[.sys$scratch:]bar
The attached patch has not been run through a full test run yet.
The problem was that catfile was expecting that the path components
were either contained VMS directory delimiters or were bare words.
The earlier part of the code detected the trailing : so knew to
treat the path a VMS.
This patch allows a path ending with a : to be treated as a VMS
directory path.
This patch is better, but still not fully tested.
Sounds good. I'll try to take it for a spin sometime soon. We also
need to sort out whether blead is a head of File::Path on CPAN or vice
versa and get synched up.
I did not run a comprehensive test of EFS mode with out Unix report
also on before, and this is exposing some dragons that are going to
take some time to slay.
I suppose one way to deal with that is to recommend they be used
together for now.
There are a number of tests and modules that will need to be adjusted
to handle VMS EFS charsets that I have found.
testp2pt.pl needs a patch as it is trying to do catfile() on directories.
cwd.t is creating an illegal symbolic link unless it is in UNIX mode,
so it does not get resolved.
ext/File-Glob/t/Basic.t is trying to compare the results of a
directory in UNIX syntax with one in VMS syntax. With EFS on, VMS
names with out extensions have the trailing periods present.
There are a few other failures that I do not understand yet.
Regards,
-John
wb8...@qsl.net
Personal Opinion Only
--- /rsync_root/perl/lib/File/Spec/VMS.pmSun May 10 04:02:09 2009
+++ lib/File/Spec/VMS.pmMon Jun 8 01:19:01 2009
@@ -195,6 +195,32 @@
if ($efs) {
# Extended character set in use, go into DWIM mode.
+if ($path =~ /:$/) {
+# We have a problem. If we do a syntax only conversion
+# we can break existing code that does not understand
how
+# logical names and directories can be combined.
+my $test_path = $path;
+my $i = 0;
+while ($i 10) {
+# We need to do a logical name check, but we do
not have
+# logical name services in perl. So we need to
$ENV until
+# that can be remedied.
+$test_path =~ s/:$//;
+my $test_trnlnm = $ENV{$test_path};
+last unless defined $test_trnlnm;
+if ($test_trnlnm =~ /\.[\]]$/) {
+# A rooted logical name, same as device so
use as is.
+last;
+}
+if ($test_trnlnm =~ /[\]]$/) {
+# Found a directory, use this instead of the
path
+$path = $test_trnlnm;
+last;
+}
+$test_path = $test_trnlnm;
+$i++;
+};
+}
I don't understand the rationale for this. I think we want foo: in
foo:bar treated like a device name whether foo is a logical name or
not. I don't think that would be a legal Unix specification, at least
not without the colon being escaped, so I don't think we should work too
hard to allow for the rare (maybe impossible) case where the colon is
supposed to be just another filename character.
Existing library code is using catdir('sys$scratch:','tempdir'). The
above code is needed for that to work.
I am not sure if I need to do something to handle if tainted is on.
}
@@ -429,6 +469,7 @@
my $spath_vms = 0;
$spath_vms = 1 if ($spath =~ m#[\[\]]#);
$spath_vms = 1 if ($spath =~ /^--?$/);
+$spath_vms = 1 if ($spath =~ /:$/);
Some thought needs to be given to performance in code like this. I
think those four lines could be replaced with
my $spath_vms = $spath eq '--' || ($spath =~ m#([\[\]]|:$)#);
There is no reason to use a regex when you are matching the entire
string, so replace C$spath =~ /^--?$/ with C$spath eq '--'. If one
check passes, we should stop checking and not do the other checks.
Combining the first and third regexes into one should be more efficient
(there are further improvements that could be made to that regex).
It also has to handle the case of $spath = '-' or $spath = '---' or
spath consisting of any number of '-' characters.
The other
Re: [blead 2009-05-29.22:08:17] vms.c EFS logical name fix.
Here is the latest attempt. Still not fully tested.
The VMS format of logical foo:bar, such as sys$scratch:foo seems to be
causing all sorts of problems.
catpath(sys$scratch:,,foo.bar) can not work. The catpath method can
not deal with an empty directory, so will treat 'foo.bar' as a
directory. So the splitpath(sys$scratch:foo.bar) must translate the
sys$scratch: to its device and directory component.
Some new regression tests that may be needed for EFS/VMS mode.
[wrapped line below]
perl -MFile::Spec::Functions -e -
print
File::Spec-abs2rel('../lib/Module/Pluggable','../lib/Module/Pluggable/');
returns .
perl -MFile::Spec::Functions -e -
print catdir('sys$scratch:','foo', 'bar');
returns device:[dir.foo.bar]'
perl -MFile::Spec::Functions -e print catdir('[]','foo', 'bar');
returns [.foo.bar]
File::Spec-splitpath('sys$scratch:compilet.exe') returns ('dev:',
'[dir]', 'compilet.exe').
It looks like there are still issues with:
ext/Test-Harness,
lib/Archive/Extract,
lib/Archive/Tar
CPANPLUS,
Various lib/ExtUtils,
lib/Module/Build,
lib/Pod/Simple
And i need to make a test run to make sure that I did not change the
working EFS/Unix and non-EFS modes.
Regards,
-John
--- /rsync_root/perl/lib/File/Spec/VMS.pm Sun May 10 04:02:09 2009
+++ lib/File/Spec/VMS.pmTue Jun 9 00:03:27 2009
@@ -105,7 +105,6 @@
sub canonpath {
my($self,$path) = @_;
-
return undef unless defined $path;
my $efs = $self-_efs;
@@ -195,6 +194,32 @@
if ($efs) {
# Extended character set in use, go into DWIM mode.
+if ($path =~ /:$/) {
+# We have a problem. If we do a syntax only conversion
+# we can break existing code that does not understand how
+# logical names and directories can be combined.
+my $test_path = $path;
+my $i = 0;
+while ($i 10) {
+# We need to do a logical name check, but we do not have
+# logical name services in perl. So we need to $ENV until
+# that can be remedied.
+$test_path =~ s/:$//;
+my $test_trnlnm = $ENV{$test_path};
+last unless defined $test_trnlnm;
+if ($test_trnlnm =~ /\.[\]]$/) {
+# A rooted logical name, same as device so use as is.
+last;
+}
+if ($test_trnlnm =~ /[\]]$/) {
+# Found a directory, use this instead of the path
+$path = $test_trnlnm;
+last;
+}
+$test_path = $test_trnlnm;
+$i++;
+}
+}
# Now we need to identify what the directory is in
# of the specification in order to merge them.
@@ -202,14 +227,14 @@
$path_unix = 1 if ($path =~ m#/#);
$path_unix = 1 if ($path =~ /^\.\.?$/);
my $path_vms = 0;
-$path_vms = 1 if ($path =~ m#[\[\]]#);
-$path_vms = 1 if ($path =~ /^--?$/);
+$path_vms = 1 if ($path =~ m#(?:[\[\]]|:$)#);
+$path_vms = 1 if ($path =~ /^--*$/);
my $dir_unix = 0;
$dir_unix = 1 if ($dir =~ m#/#);
$dir_unix = 1 if ($dir =~ /^\.\.?$/);
my $dir_vms = 0;
$dir_vms = 1 if ($dir =~ m#[\[\]]#);
-$dir_vms = 1 if ($dir =~ /^--?$/);
+$dir_vms = 1 if ($dir =~ /^--*$/);
my $unix_mode = 0;
if (($path_unix != $dir_unix) ($path_vms != $dir_vms)) {
@@ -237,20 +262,31 @@
#with posible instead of [.
# Normalize the brackets
# Fixme - need to not switch when preceded by ^.
-$path =~ s//\[/g;
-$path =~ s//\]/g;
+if ($path !~ /:$/) {
+$path =~ s//\[/g;
+$path =~ s//\]/g;
+}
$dir =~ s//\[/g;
$dir =~ s//\]/g;
# Fix up mixed syntax imput as good as possible - GIGO
-$path = vmsify($path) if $path_unix;
-$dir = vmsify($dir) if $dir_unix;
+if ($path_unix) {
+$path = vmspath($path);
+$path_vms = 1;
+$path_unix = 0;
+}
+if ($dir_unix) {
+$dir = vmspath($dir);
+$dir_vms = 1;
+$dir_unix = 0;
+}
#Possible path values: foo: [.foo] [foo] foo, and $(foo)
#or starting with '-', or foo.dir
#If path is foo, it needs to be converted to [.foo]
# Fix up a bare path name.
+my $is_abs_path = 0;
Re: [blead 2009-05-29.22:08:17] vms.c EFS logical name fix.
Craig A. Berry wrote:
I went back to my original test case (not the narrower one you ended up
fixing) and it looks like we are half-way there. If both
DECC$EFS_CHARSET and DECC$FILENAME_UNIX_REPORT are defined, this works:
$ perl -MFile::Spec::Functions -e print catfile(File::Spec-tmpdir(),
'bar');
/sys$scratch/bar
but if only DECC$EFS_CHARSET is defined, it doesn't:
$ perl -MFile::Spec::Functions -e print catfile(File::Spec-tmpdir(),
'bar');
[.sys$scratch:]bar
The attached patch has not been run through a full test run yet.
The problem was that catfile was expecting that the path components were
either contained VMS directory delimiters or were bare words.
The earlier part of the code detected the trailing : so knew to treat
the path a VMS.
This patch allows a path ending with a : to be treated as a VMS
directory path.
-John
wb8...@qsl.net
Personal Opinion Only
--- /rsync_root/perl/lib/File/Spec/VMS.pm Sun May 10 04:02:09 2009
+++ lib/File/Spec/VMS.pmSun Jun 7 13:01:54 2009
@@ -445,7 +445,12 @@
$spath = '[' . $spath . ']' if $spath =~ /^-/;
$rslt = vmspath($spath);
} else {
-$rslt = '[.' . $spath . ']';
+if ($spath =~ /:$/) {
+# Handle device name with out directory for path.
+$rslt = $spath;
+} else {
+$rslt = '[.' . $spath . ']';
+}
}
$file = vmsify($file) if ($file_unix);
} else {
[blead 2009-05-29.22:08:17] vms.c EFS logical name fix.
This patch fixes an issue that Craig Berry found in the handling of
logical names of the form foo = device:[dir] when the EFS character
set is enabled.
Regards,
-John
wb8...@qsl.net
Personal Opinion Only
--- /rsync_root/perl/vms/vms.c Sun Feb 22 21:22:09 2009
+++ vms/vms.c Tue Jun 2 20:42:26 2009
@@ -8231,7 +8231,7 @@
* special device files.
*/
- if ((add_6zero == 0) (*nextslash == '/')
+ if (!islnm (add_6zero == 0) (*nextslash == '/')
(nextslash[1] == unixend)) {
/* No real directory present */
add_6zero = 1;
@@ -8491,7 +8491,7 @@
vmsptr2 = vmsptr - 1;
if ((vmslen 1)
(*vmsptr2 != ']') (*vmsptr2 != '*') (*vmsptr2 != '%')
- (*vmsptr2 != ')') (*lastdot != '.')) {
+ (*vmsptr2 != ')') (*lastdot != '.') (*vmsptr2 != ':')) {
*vmsptr++ = '.';
vmslen++;
}
@@ -8677,7 +8677,7 @@
}
}
-/* If POSIX mode active, handle the conversion */
+/* If EFS charset mode active, handle the conversion */
#if __CRTL_VER = 8020 !defined(__VAX)
if (decc_efs_charset) {
posix_to_vmsspec_hardway(rslt, rslt_len, path, dir_flag, utf8_flag);
Re: [blead 2009-05-29.22:08:17] vms.c EFS logical name fix.
Craig A. Berry wrote: On Thu, Jun 4, 2009 at 9:18 AM, Craig A. Berry craigbe...@mac.com wrote: On Jun 4, 2009, at 8:46 AM, John E. Malmberg wrote: This patch fixes an issue that Craig Berry found in the handling of logical names of the form foo = device:[dir] when the EFS character set is enabled. Looks good. Can we add a test case for this? I went ahead and did that here: http://perl5.git.perl.org/perl.git/commitdiff/50255d5 Thanks. I did not have time to write a test this morning. Regards, -John wb8...@qsl.net Personal Opinion Only
bllead broken?
Craig A. Berry wrote: Thanks. The blead build is currently broken so don't synch first. Hopefully we'll get it all sorted out soonish. I just tried to sync up with blead and it stopped at writing Descrip.mms for Attribute::Handlers. Is that the issue that you are seeing? -John wb8...@qsl.net Personal Opinion Only
Re: device name problems with extended charset and File::Spec
Craig A. Berry wrote:
With current blead, if I define both DECC$EFS_CHARSET and
DECC$EFS_FILENAME_UNIX_REPORT, I see the following:
$ perl -MFile::Spec::Functions -e print catfile(File::Spec-tmpdir(),
'bar');
./bar
Obviously it should be giving me '/sys$scratch/bar'.
With only DECC$EFS_CHARSET defined, I get:
$ perl -MFile::Spec::Functions -e print catfile(File::Spec-tmpdir(),
'bar');
[.sys$scratch:]bar
where it's apparently failed to recognize 'sys$scratch:' as a device
name. The colon is not escaped, so the result is not even a valid
filespec, much less the correct one.
Are there changes to File::Path kicking around somewhere that are not
yet in blead, or is this still a todo?
The bug is in vms.c, not File::Spec. These two one liners demonstrate it:
EAGLE perl -e print 'true' if -w '/sys$scratch'
EAGLE perl -e print 'true' if -w 'sys$scratch:'
true
Something is wrong with the stat code. I will try to look at it tonight.
In file::spec-_tmpdir() the -w test is used to make sure that the temp
directory is writable, and it falls back to . if it can not find one
of '/tmp', '/sys$scratch', or $ENV{tempdir} as writable.
-John
wb8...@qsl.net
Personal Opinion Only
Re: device name problems with extended charset and File::Spec
John E. Malmberg wrote:
Craig A. Berry wrote:
With current blead, if I define both DECC$EFS_CHARSET and
DECC$EFS_FILENAME_UNIX_REPORT, I see the following:
$ perl -MFile::Spec::Functions -e print
catfile(File::Spec-tmpdir(), 'bar');
./bar
Obviously it should be giving me '/sys$scratch/bar'.
With only DECC$EFS_CHARSET defined, I get:
$ perl -MFile::Spec::Functions -e print
catfile(File::Spec-tmpdir(), 'bar');
[.sys$scratch:]bar
where it's apparently failed to recognize 'sys$scratch:' as a device
name. The colon is not escaped, so the result is not even a valid
filespec, much less the correct one.
Are there changes to File::Path kicking around somewhere that are not
yet in blead, or is this still a todo?
The bug is in vms.c, not File::Spec. These two one liners demonstrate it:
EAGLE perl -e print 'true' if -w '/sys$scratch'
EAGLE perl -e print 'true' if -w 'sys$scratch:'
true
Something is wrong with the stat code. I will try to look at it tonight.
To be more precise, the problem has to be in the perl_cando code.
In file::spec-_tmpdir() the -w test is used to make sure that the temp
directory is writable, and it falls back to . if it can not find one
of '/tmp', '/sys$scratch', or $ENV{tempdir} as writable.
-John
wb8...@qsl.net
Personal Opinion Only
Re: device name problems with extended charset and File::Spec
Craig A. Berry wrote:
On Jun 2, 2009, at 8:39 AM, John E. Malmberg wrote:
John E. Malmberg wrote:
The bug is in vms.c, not File::Spec. These two one liners
demonstrate it:
EAGLE perl -e print 'true' if -w '/sys$scratch'
EAGLE perl -e print 'true' if -w 'sys$scratch:'
true
Something is wrong with the stat code. I will try to look at it
tonight.
To be more precise, the problem has to be in the perl_cando code.
In file::spec-_tmpdir() the -w test is used to make sure that the
temp directory is writable, and it falls back to . if it can not
find one of '/tmp', '/sys$scratch', or $ENV{tempdir} as writable.
Thanks. The blead build is currently broken so don't synch first.
Hopefully we'll get it all sorted out soonish.
I am glad that I did not. I am running a test build now.
It was in the EFS internal version of vmsify(/SYS$SCRATCH). It was
incorrectly translating it to SYS$SCRATCH:[00].
I am a bit surprised that this did not show up sooner. In addition to
the patch to VMS.C, I need to add a test for this.
-John
wb8...@qsl.net
Personal Opinion Only
Resend, lib/file/compare.t patch for VMS.
The lib/file/compare.t test has never been correct for VMS, but the bugs
where mostly hidden until testing on a ODS-5 volume with that allows
filenames with more characters in them than VMS traditionally allows.
This is known as EFS_CHARSET mode.
This also exposes that the vmsify() routine in the traditional VMS mode
is not matching how the C library in VMS internally implements the
equivalent function.
I am not sure that we want to change the vmsify() function traditional
VMS mode behavior at this time.
It also exposes that the flush() operation is a no-op on the VMS
platform, which is something that needs to be fixed.
This issue with flush() has shown up before, but the test was modified
to not use that algorithm.
The DECC$FILE_SHARING feature needs to be active for this test to work
when the EFS_CHARSET mode is on. By default DECC$FILE_SHARING is off,
and so far none of the other Perl tests need it enabled, even when in
UNIX compatible mode.
This patch fixes the lib/file/compare.t test to actually work the way it
was intended to on VMS when VMS is in the traditional mode, and not
leave extra files behind in SYS$SCRATCH:
On VMS SYS$SCRATCH: by default behaves like a user private copy of /tmp
on Unix.
This patch also adds diagnostics so that explains what is wrong when VMS
is run in the EFS_CHARSET mode. As DECC$FILE_SHARING is not normally
active, it has a check to skip the tests that require it.
The last e-mail from Craig that I saw about the initial submission where
he was not sure about the extra diagnostics, but was going to look it
over, and I did not see a response to my more detailed post about patch
and why these diagnostics are needed.
Regards,
-John
wb8...@qsl.net
Personal Opinion Only
--- /rsync_root/perl/lib/File/compare.t Tue Jun 13 14:29:14 2006
+++ lib/File/compare.t Mon Nov 24 19:24:36 2008
@@ -14,6 +14,28 @@
}
}
+my $vms_unix_rpt = 0;
+my $vms_efs = 0;
+my $vms_file_sharing = 0;
+my $vms_default_mode = 0;
+
+if ($^O eq 'VMS') {
+$vms_default_mode = 1;
+if (eval 'require VMS::Feature') {
+$vms_unix_rpt = VMS::Feature::current('filename_unix_report');
+$vms_efs = VMS::Feature::current('efs_charset');
+$vms_file_sharing = VMS::Feature::current('file_sharing');
+} else {
+my $unix_rpt = $ENV{'DECC$FILENAME_UNIX_REPORT'} || '';
+my $efs_charset = $ENV{'DECC$EFS_CHARSET'} || '';
+my $file_sharing = $ENV{'DECC$FILE_SHARING'} || '';
+$vms_unix_rpt = $unix_rpt =~ /^[ET1]/i;
+$vms_efs = $efs_charset =~ /^[ET1]/i;
+$vms_file_sharing = $file_sharing =~ /^[ET1]/i;
+}
+$vms_default_mode = 0 if ($vms_efs $vms_file_sharing);
+}
+
print 1..13\n;
use File::Compare qw(compare compare_text);
@@ -78,7 +100,16 @@
my $template = File::Spec-catfile(File::Spec-tmpdir, 'fcmp');
my($tfh,$filename) = mkstemp($template);
+
# NB. The trailing space is intentional (see [perl #37716])
+
+ # With the default VMS mode, the trailing space is stripped off
+ # silently. Which means we open a second version of the same filename.
+ # Which makes the code below appear to work until the extended character
+ # set becomes available. Then the two filenames are different, and
+ # this test attempts to open a file already open by the temp file handle.
+ # by default VMS does not allow this unless DECC$FILE_SHARING is set.
+
open my $tfhSP, , $filename
or die Could not open '$filename ' for writing: $!;
binmode($tfhSP);
@@ -93,25 +124,62 @@
print $tfhSP $data;
close($tfhSP);
}
+
+ # X/Open requires this if you expect the data to actually be readable
+ # by other streams, but this only affects VMS.
+ if ($vms_file_sharing) {
+ $tfh-flush or die Could not flush filehandle: $!;
+ }
+
seek($tfh,0,0);
$donetests[0] = compare($tfh, 'README');
$donetests[1] = compare($filename, 'README');
- unlink0($tfh,$filename);
+
+ # In VMS default mode, this unlink fails because it sees $filename.' '
+ # instead of $filename and it is not the file handled that is open.
+ # So we can not do this until after $filename.'' is unlinked.
+ unlink0($tfh,$filename) unless $vms_default_mode;
+
$donetests[2] = compare('README', $filename );
unlink $filename ;
+
+ # In VMS default mode, clean this up now.
+ unlink0($tfh,$filename) if $vms_default_mode;
};
print # problem '$@' when testing with a temporary file\n if $@;
if (@donetests == 3) {
print not unless $donetests[0] == 0;
- print ok 11 # fh/file [$donetests[0]]\n;
- print not unless $donetests[1] == 0;
- print ok 12 # file/file [$donetests[1]]\n;
+ print ok 11 # fh/file [$donetests[0]] \n;
+ unless ($donetests[1] == 0) {
+ if ($vms_file_sharing) {
+ $vms_todo_flush = TODO - flush() not implmented on VMS; ;
+ } else {
+ print # DECC\$FILE_SHARING needs to be enabled for test 12\n;
+ }
+ print not ;
+ }
+ print ok 12 #
Re: Resend, lib/file/compare.t patch for VMS.
Craig A. Berry wrote: On May 30, 2009, at 12:39 PM, John E. Malmberg wrote: The lib/file/compare.t test has never been correct for VMS, but the bugs where mostly hidden until testing on a ODS-5 volume with that allows filenames with more characters in them than VMS traditionally allows. This is known as EFS_CHARSET mode. I think you are right that the test that intentionally has a space in the filename is not working right in traditional mode. The correct fix would be to detect whether files with spaces in the name are actually supported and skip that test if not. This also exposes that the vmsify() routine in the traditional VMS mode is not matching how the C library in VMS internally implements the equivalent function. There are no explicit vmsify calls in the test, so I don't know what you are referring to. I am referring to the internal calls to convert Unix to VMS filenames in VMS.C which the vmsify() routine is a wrapper for. The CRTL is discarding space characters found in UNIX format filenames when converting them to VMS. The code that implements vmsify() does not do that. If it had, this issue would have been seen before. It also exposes that the flush() operation is a no-op on the VMS platform, which is something that needs to be fixed. I don't think it's working any differently than anywhere else. You may be getting confused by the fact that calling flush() on a filehandle only flushes the perlio buffers and does not implicitly do an fflush(), much less an fsync(), on the underlying file descriptor. This issue with flush() has shown up before, but the test was modified to not use that algorithm. The DECC$FILE_SHARING feature needs to be active for this test to work when the EFS_CHARSET mode is on. By default DECC$FILE_SHARING is off, and so far none of the other Perl tests need it enabled, even when in UNIX compatible mode. Flushing and file sharing aren't really relevant. When calling File::Compare::compare with a filename rather than a handle, we just need to make sure the file is closed first on VMS. That's it. This test is expecting that the data written to the file by one file handle can be read by the second file handle while the first file handle is open. According to X/Open, the only way to guarantee that is to call a fsync() call. The IO-flush is the closest thing to that, and when I checked the source code a while back, I discovered that it was not doing anything. We should be able to fix Perl on VMS so that this test runs the same way on VMS as it does on UNIX when the extended file specifications are active, and the UNIX file sharing mode is set. For the traditional VMS mode, I think that the test should be modified or skipped, but for using extended file specifications, the original algorithm should work. The last e-mail from Craig that I saw about the initial submission where he was not sure about the extra diagnostics, but was going to look it over, and I did not see a response to my more detailed post about patch and why these diagnostics are needed. Sorry not to follow up in a timely fashion. I'll try to do better this time. I have something mostly working that just needs a bit more testing. Regards, -John wb8...@qsl.net Personal Opinion Only
Re: maint-5.10-1196-ga8a43ff on VMS status
Dave Mitchell wrote: On Sun, May 24, 2009 at 04:38:15PM -0500, John E. Malmberg wrote: Craig A. Berry wrote: I think that some of my patches to allow the ExtUtils modules to work with the Extended Character sets on ODS-5 volumes and the UNIX report modes have not yet made it into the CPAN versions. This is what is still different from what I have. From the earlier discussion, it looks like some commits might have been made to blead that did not show up in perl.perl5.changes. When that happens, my copy of blead gets out of synch. Do you have a list (eg module names and RT IDs?) https://rt.cpan.org/Ticket/Display.html?id=42149 lib/ExtUtils/Install.pm lib/ExtUtils.t/INST.t lib/ExtUtils/t/INST_PREFIX.t https://rt.cpan.org/Ticket/Display.html?id=42151 lib/ExtUtils/MM_Unix.pm lib/ExtUtils/MM_VMS.pm lib/ExtUtils/t/recurs.t https://rt.cpan.org/Ticket/Display.html?id=42150 lib/ExtUtils/t/basic.pl https://rt.cpan.org/Ticket/Display.html?id=42148 lib/Test/Simple/t/exit.t https://rt.cpan.org/Ticket/Display.html?id=42147 lib/ExtUtils/t/Embed.t https://rt.cpan.org/Ticket/Display.html?id=42724 https://rt.cpan.org/Ticket/Display.html?id=42157 Some of these are in, but some are not. lib/ExtUtils.CBuilder.Platform/VMS.pm lib/Module/Build/Compat.pm - Ticket 41331. lib/ExtUtils.Cbuilder.t]01-basic.t lib/ExtUtils.Cbuilder.t]02-link.t I thought I have this filed somewhere in the above tickets, but this is an issue of the test leaving work files behind. Not sure where the bug is right now. lib/Module/Build/t/extend.t lib/Module/Build/t/install.t lib/Module/Build/t/metadata.t lib/Module/Build/t/runthrough.t lib/Module/Build/t/lib/DistGen.pm These should be in the above CPAN tickets for Module Build. lib/File/Compare.t has existing bugs that show up when VMS is run with the extended filename character set enabled. I submitted a patch that diagnoses the bugs to explain why the test will not work until Perl is updated. This was submitted to blead, so I do not have a ticket. t/op/taint.t has a test that is exposing an tainting issue on VMS when run with a world writable temp directory. I submitted a patch to skip the tests with a TODO. This was submitted to blead so I do not have a ticket. Regards, -John
Re: maint-5.10-1196-ga8a43ff on VMS status
John E. Malmberg wrote: Dave Mitchell wrote: On Sun, May 24, 2009 at 04:38:15PM -0500, John E. Malmberg wrote: Craig A. Berry wrote: I think that some of my patches to allow the ExtUtils modules to work with the Extended Character sets on ODS-5 volumes and the UNIX report modes have not yet made it into the CPAN versions. This is what is still different from what I have. From the earlier discussion, it looks like some commits might have been made to blead that did not show up in perl.perl5.changes. When that happens, my copy of blead gets out of synch. Do you have a list (eg module names and RT IDs?) https://rt.cpan.org/Ticket/Display.html?id=42149 lib/ExtUtils/Install.pm lib/ExtUtils.t/INST.t lib/ExtUtils/t/INST_PREFIX.t https://rt.cpan.org/Ticket/Display.html?id=42151 lib/ExtUtils/MM_Unix.pm lib/ExtUtils/MM_VMS.pm lib/ExtUtils/t/recurs.t https://rt.cpan.org/Ticket/Display.html?id=42150 lib/ExtUtils/t/basic.pl https://rt.cpan.org/Ticket/Display.html?id=42148 lib/Test/Simple/t/exit.t https://rt.cpan.org/Ticket/Display.html?id=42147 lib/ExtUtils/t/Embed.t https://rt.cpan.org/Ticket/Display.html?id=42724 https://rt.cpan.org/Ticket/Display.html?id=42157 Some of these are in, but some are not. lib/ExtUtils.CBuilder.Platform/VMS.pm lib/Module/Build/Compat.pm - Ticket 41331. lib/ExtUtils.Cbuilder.t]01-basic.t lib/ExtUtils.Cbuilder.t]02-link.t I thought I have this filed somewhere in the above tickets, but this is an issue of the test leaving work files behind. Not sure where the bug is right now. lib/Module/Build/t/extend.t lib/Module/Build/t/install.t lib/Module/Build/t/metadata.t lib/Module/Build/t/runthrough.t lib/Module/Build/t/lib/DistGen.pm These should be in the above CPAN tickets for Module Build. lib/File/Compare.t has existing bugs that show up when VMS is run with the extended filename character set enabled. I submitted a patch that diagnoses the bugs to explain why the test will not work until Perl is updated. This was submitted to blead, so I do not have a ticket. t/op/taint.t has a test that is exposing an tainting issue on VMS when run with a world writable temp directory. I submitted a patch to skip the tests with a TODO. This was submitted to blead so I do not have a ticket. I missed lib/File/Path.t, which has a test that is invalid on VMS, but this only shows up as an issue when VMS is in the Unix compatible mode. This was submitted to blead, so I do not have a ticket. -John wb8...@qsl.net Personal Opinion Only
patch@2009-05-25.21:50:08 magic.t leaves $ENV{foo} on VMS.
This patches Magic.t to remove the $ENV{foo} it created on VMS.
This environment variable interferes with running other tests including
CPAN tests.
-John
wb8...@qsl.net
Personal Opinion Only
--- /rsync_root/perl/t/op/magic.t Fri May 22 11:40:09 2009
+++ t/op/magic.tMon May 25 20:22:42 2009
@@ -30,6 +30,11 @@
$Is_MSWin32? '.\perl' :
'./perl');
+END {
+# On VMS, environment variable changes are peristent after perl exits
+delete $ENV{'FOO'} if $Is_VMS;
+}
+
eval '$ENV{FOO} = hi there;'; # check that ENV is inited inside eval
# cmd.exe will echo 'variable=value' but 4nt will echo just the value
# -- Nikola Knezevic
patch@2009-05-25.21:50:08 perl5db.t leaves db.out behind on VMS
This patch fixes lib/perl5db.t to not leave a db.out file behind on VMS
after a test run.
-John
wb8...@qsl.net
Personal Opinion Only
--- /rsync_root/perl/lib/perl5db.t Fri Dec 19 03:14:10 2008
+++ lib/perl5db.t Mon May 25 16:02:21 2009
@@ -85,5 +85,5 @@
# clean up.
END {
-unlink qw(.perldb db.out);
+1 while unlink qw(.perldb db.out);
}
patch@2009-05-25.21:50:08 text-options.t file cleanup on VMS
This patch fixes lib/Pod/text-options.t to not leave tmp.pod and out.tmp
files behind on VMS.
-John
wb8...@qsl.net
Personal Opinion Only
--- /rsync_root/perl/lib/Pod/t/text-options.t Fri Dec 19 03:14:10 2008
+++ lib/Pod/t/text-options.tMon May 25 16:23:28 2009
@@ -69,7 +69,7 @@
$output = TMP;
}
close TMP;
-unlink ('tmp.pod', 'out.tmp');
+1 while unlink ('tmp.pod', 'out.tmp');
my $expected = '';
while (DATA) {
last if $_ eq ###\n;
Re: maint-5.10-1196-ga8a43ff on VMS status
Craig A. Berry wrote: With everything default except -Duseithreads, I see: Failed 6 tests out of 1564, 99.62% okay. [-.lib.CPANPLUS.Dist.Build.t]02_CPANPLUS-Dist-Build.t [-.lib.CPANPLUS.t]19_CPANPLUS-Dist.t [-.lib.ExtUtils.t]basic.t [-.lib.Module.Build.t]compat.t [-.lib.Module.Build.t]ext.t op/magic.t Here's what I know about what fixes these. [-.lib.CPANPLUS.Dist.Build.t]02_CPANPLUS-Dist-Build.t [-.lib.CPANPLUS.t]19_CPANPLUS-Dist.t These require the integration of http://perl5.git.perl.org/perl.git/commitdiff/41cb7b2 from blead plus the patch to IPC::Cmd at http://rt.cpan.org/Public/Bug/Display.html?id=46288 being rolled into a release and working its way downstream. [-.lib.ExtUtils.t]basic.t This is fixed in EU::MM 6.51_03, though that has a couple of new and different failures that will hopefully be sorted out shortly. [-.lib.Module.Build.t]compat.t [-.lib.Module.Build.t]ext.t These are resolved in the M::B development stream (specifically at http://rt.cpan.org/Public/Bug/Display.html?id=42724) but await percolation through a release, blead, and thus to maint. Should we go ahead and put a development snapshot of M::B into blead? op/magic.t Minor collateral damage from converting the test to t/test.pl, fixed in blead at http://perl5.git.perl.org/perl.git/commitdiff/ae8ade6. magic.t in my tests is leaving behind a logical name named foo which is causing failures in the CPANPLUS tests as it prevents access to a directory named foo that they use. I think that some of my patches to allow the ExtUtils modules to work with the Extended Character sets on ODS-5 volumes and the UNIX report modes have not yet made it into the CPAN versions. -John wb8...@qsl.net Personal Opinion Only
Re: Data overrun in Perl_magic_get '?' (Was: Access violation in SV.C new_body_inline())
Craig A. Berry wrote:
On May 18, 2009, at 11:54 PM, John E. Malmberg wrote:
John E. Malmberg wrote:
The trail has taken me to the following lines just below the comment
with the tag AMS 20010810.
while(mg) {
const MGVTBL * const vtbl = mg-mg_virtual;
if (!(mg-mg_flags MGf_GSKIP) vtbl vtbl-svt_get) {
CALL_FTPR(vtbl-sv_get)(aTHX_ sv, mg);
On the return from this call, the Ibody_roots[7] is corrupted.
*vtbl-sv_get at this point is loaded with the function Perl_magic_get,
and the value it is looking for is the '?'.
And looking there, I find VMS specific code where the
my_perl-Istatusvalue_vms is put into sv-sv_any-slv_targlen.
Istatusvalue_vms contains 44, the same bad pointer value.
The body size for type SVt_PVMG (7) appears to be 32, which means that
the LvTARGLEN(sv) writing at offset 32 is the culprit, corrupting the
linked list.
I am not sure how to fix this, but now that I have found out this
much, maybe someone else here can?
So you're saying that these lines in Perl_magic_get in mg.c:
case '?':
{
sv_setiv(sv, (IV)STATUS_CURRENT);
#ifdef COMPLEX_STATUS
LvTARGOFF(sv) = PL_statusvalue;
LvTARGLEN(sv) = PL_statusvalue_vms;
#endif
}
are where the damage occurs? So it looks like the SV in question does
not even have the relevant slots (xlv_targlen) we're trying to update
here.
Yes.
I wonder if it's because IPC::Cmd declares $? as local. Maybe we
are assuming $? is always lexical but it's not?
I do not know.
-John
wb8...@qsl.net
Personal Opinion Only
Data overrun in Perl_magic_get '?' (Was: Access violation in SV.C new_body_inline())
John E. Malmberg wrote:
The trail has taken me to the following lines just below the comment
with the tag AMS 20010810.
while(mg) {
const MGVTBL * const vtbl = mg-mg_virtual;
if (!(mg-mg_flags MGf_GSKIP) vtbl vtbl-svt_get) {
CALL_FTPR(vtbl-sv_get)(aTHX_ sv, mg);
On the return from this call, the Ibody_roots[7] is corrupted.
*vtbl-sv_get at this point is loaded with the function Perl_magic_get,
and the value it is looking for is the '?'.
And looking there, I find VMS specific code where the
my_perl-Istatusvalue_vms is put into sv-sv_any-slv_targlen.
Istatusvalue_vms contains 44, the same bad pointer value.
The body size for type SVt_PVMG (7) appears to be 32, which means that
the LvTARGLEN(sv) writing at offset 32 is the culprit, corrupting the
linked list.
I am not sure how to fix this, but now that I have found out this much,
maybe someone else here can?
-John
wb8...@qsl.net
Personal Opinion Only
Re: Data overrun in Perl_magic_get '?' (Was: Access violation in SV.C new_body_inline())
Nicholas Clark wrote:
On Tue, May 19, 2009 at 08:18:17AM -0500, John E. Malmberg wrote:
Craig A. Berry wrote:
So you're saying that these lines in Perl_magic_get in mg.c:
case '?':
{
sv_setiv(sv, (IV)STATUS_CURRENT);
#ifdef COMPLEX_STATUS
LvTARGOFF(sv) = PL_statusvalue;
LvTARGLEN(sv) = PL_statusvalue_vms;
#endif
}
are where the damage occurs? So it looks like the SV in question does
not even have the relevant slots (xlv_targlen) we're trying to update
here.
Yes.
I wonder if it's because IPC::Cmd declares $? as local. Maybe we
are assuming $? is always lexical but it's not?
I do not know.
That code rings a bell. The only thing I can find that I did near it was:
http://perl5.git.perl.org/perl.git/commit/35f998ddd1e1665f7d0899ae3e50f9262c59d848
However I had a suspicion that I also did something that restricted the upgrade
to the minimal case.
I don't think that lexical has anything to do with it - I suspect that the
bug is because IPC::Cmd localises $?, and the new scalar is created like this:
STATIC SV *
S_save_scalar_at(pTHX_ SV **sptr, const U32 flags)
{
dVAR;
SV * const osv = *sptr;
register SV * const sv = *sptr = newSV(0);
PERL_ARGS_ASSERT_SAVE_SCALAR_AT;
if (SvTYPE(osv) = SVt_PVMG SvMAGIC(osv) SvTYPE(osv) != SVt_PVGV) {
if (SvGMAGICAL(osv)) {
const bool oldtainted = PL_tainted;
SvFLAGS(osv) |= (SvFLAGS(osv)
(SVp_IOK|SVp_NOK|SVp_POK)) PRIVSHIFT;
PL_tainted = oldtainted;
}
mg_localize(osv, sv, (flags SAVEf_SETMAGIC) != 0);
}
return sv;
}
where that call to mg_localize() will upgrade it to PVMG, but not PVLV.
If this is the cause, I'm not sure whether the correct fix is to make
mg_localize generally upgrade the new scalar to the type of the existing
scalar, or special case it for $?.
My vote would be that the mg_localize code should always want to make
sure that the new scalar could contain any value that the existing scalar.
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
Some progress: I have not been able to find a connection between the code 44 returned by the system() routine and the memory getting corrupted. By putting in code to periodically check the Ibody_root[7] linked list, the data corruption is occurring in SvSetMagic/Perl_pp_assign which is called by Perl_pp_assign just before it returns. Before the call, there is no corruption in the linked list. The corruption occurs before the call to Perl_sv_upgrade line that is below the case SVt_PVMG: label. My next step is to put some checks in the Perl_sv_setsv_flags() routines to try to isolate where the linked list is being zapped. -John wb8...@qsl.net Personal Opinion Only
Re: maint-5.10-1131-gdfc0ab6 on VMS status
Craig A. Berry wrote: On May 10, 2009, at 4:27 PM, Dave Mitchell wrote: On Thu, May 07, 2009 at 08:52:54PM -0500, John E. Malmberg wrote: Craig A. Berry wrote: With a -Duseithreads build using HP C V7.3-018 on OpenVMS IA64 V8.3-1H1, I get: ext/Cwd/t/cwd.FAILED at test 23 lib/Archive/Extract/t/01_Archive-Extract..FAILED at test 74 lib/CPANPLUS/Dist/Build/t/02_CPANPLUS-Dist-Build..FAILED at test 11 lib/CPANPLUS/t/19_CPANPLUS-Dist...FAILED at test 62 lib/ExtUtils/t/basic..FAILED--expected 81 tests, saw 84 lib/Module/Build/t/compat.FAILED at test 22 lib/Module/Build/t/extFAILED at test 142 Failed 7 tests out of 1560, 99.55% okay. This is identical to blead except for the Cwd test, which succeeds in blead. The next step is digging around in all the relevant RT queues to see what's already been fixed but not brought into the core yet. As of blead 2009-04-25.23.16:08, with the patches that I have previously submitted, I only have the two CPANPLUS tests failing. Are these previously-submitted patches yet to be applied to blead, and if so, is that due to waiting on upstream maintainers? I think there's a mix. If there is more than a screenful of smoke, or something I know about has been languishing in an RT queue a long time, I may apply it to blead, but otherwise I wait for upstream. I don't know offhand which patches John is referring to or what queues they are in. I hope to find time to research that soon but can't make any promises. I'm about to try a maint-5.10 build again and see where the PathTools integration got us. The basic.t and ext.t have been applied to CPAN but apparently have not made it into blead yet. I am not sure about the compat.t issue, I do not show a different compat.t than blead. I am not showing any differences in my code to the last time I synced with blead for Archive::Tar. I have not been updating my local setup as I am trying to find out what is causing the access violation in SV.C first. I do not know if I can find it before the Dayton Hamfest. -John wb8...@qsl.net Personal Opinion Only
Re: Math::Pari
Mark Berryman wrote: I need to install the Net::SSH::Perl module in Perl V5.10.0 on VMS V8.3 which means I need the Math::Pari module. Unfortunately, the build code for this module generates extensive Unix syntax and I don't know enough about the build process within Perl to fix it. This is probably the least portable perl module I have ever come across. In my experience there are several things to look for: * catfile being used where catdir is expected. * catfile and friends converting Unix syntax to VMS syntax. * Missing routines. * Filenames that are not legal on ODS-2. Is there anyone on this list who would be willing to help me get a working version of this module on VMS? I will not be able to do anything but try to answer questions for the next two weeks or so. If you can run Perl on a DECTerm, you can use a special feature of the Perl debugger that is available with 5.10.0 on VMS and will be available again on Unix with a later version or maintenance releases on Unix/Cygwin. (When I added the feature to Perl on VMS, I did not realize it was broken on Unix). $ define TERM xterm !case is important $ define PERLDB_PIDS XXX !If you abort a debug run, redo this. $ define DISPLAY Yourhost:0.0 ! Contents are currently ignored. Then when you use the -d flag when launching perl, a new DECTerm will be created which you can use with the I/O separate from program you are debugging. And then in general each time that the debugged program launches a new instance of perl, a new DECTerm window will show up so that you can debug it separately. This is important because a lot of times a perl script being debugged will redirect I/O so you can not see things in the debugger, or the debugger prompt will overwrite what you want to see in the program. If you use the spawn process option in the debugger, the spawned process does I/O in the program window, not the debug window. Your other option is to use a current build of blead-perl which may have its own quirks, and set the logical names in the VMS specific pod files for Unix compatibility. You may find that the existing build procedure will just work. I meant to put that stuff in the 5.10.0 release, but it does not work quite right and needs support from the perl library modules. That support (with a few minor exceptions) is now in blead-perl. -John wb8...@qsl.net Personal Opinion Only
Re: maint-5.10-1131-gdfc0ab6 on VMS status
Craig A. Berry wrote: With a -Duseithreads build using HP C V7.3-018 on OpenVMS IA64 V8.3-1H1, I get: ext/Cwd/t/cwd.FAILED at test 23 lib/Archive/Extract/t/01_Archive-Extract..FAILED at test 74 lib/CPANPLUS/Dist/Build/t/02_CPANPLUS-Dist-Build..FAILED at test 11 lib/CPANPLUS/t/19_CPANPLUS-Dist...FAILED at test 62 lib/ExtUtils/t/basic..FAILED--expected 81 tests, saw 84 lib/Module/Build/t/compat.FAILED at test 22 lib/Module/Build/t/extFAILED at test 142 Failed 7 tests out of 1560, 99.55% okay. This is identical to blead except for the Cwd test, which succeeds in blead. The next step is digging around in all the relevant RT queues to see what's already been fixed but not brought into the core yet. As of blead 2009-04-25.23.16:08, with the patches that I have previously submitted, I only have the two CPANPLUS tests failing. -John wb8...@qsl.net Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
John E. Malmberg wrote:
Craig A. Berry wrote:
On May 3, 2009, at 9:20 PM, John E. Malmberg wrote:
John E. Malmberg wrote:
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid
pointer.
From looking at the source code, it appears that the linked list of
bodies is corrupted. my_perl-Ibodyroots[7] has 44.
Yes, I see the same thing.
I have been looking at the S_more_bodies routine. Would it be
practical to put an assert on for a pointer being added to the linked
list with a value above 512? On VMS, the first page of memory is
protected no access.
I haven't had much time to poke at this, but I think an assert there
would only help if the body is created with a bogus pointer in the
SVt_PVMG slot rather than created with a good pointer that gets
clobbered later, and I think the second explanation is more likely. I
merely observe (without yet a chance fully to pursue) that 44 is a
suspicious number on a couple of different fronts.
I put some asserts in, and can confirm that the linked list is not
corrupted when it is set up.
With the bodies code, a arena of memory is allocated and for the body
type 7 in question, it is divided up into 32 byte chunks.
So it is possible that there is a buffer overrun if something writes 40
bytes into the body.
That might be possible if some struct is being cast on the memory and it
has a different size on VMS than on other platforms due to alignment
issues. On Alpha / VMS by default the compiler adds padding to
structures so that the members are more naturally aligned.
The structure below will have a size of 64 bits as padding will be added
to have member b start on a longword boundary.
struct foo {
char a;
long b;
}
The corruption is consistently on this same linked list.
If this were the case of a memory cell being used after it was freed, I
would expect corruptions to occur in more random places.
Running with -Dm shows that various 44-byte chunks of memory get
allocated, including arenas that are multiples of 44 in size, so if
there is a legitimate size of 44 that is added to something that
should be a good value but is actually NULL, that might be one
explanation for where the bad smell is coming from.
44 / 0x2c is the value of SS$_ABORT, which is the return value of the
system() call in IPC::Cmd::_run, which is called somewhere in the
chain following from CPANPLUS::Dist::_resolve_prereqs.[1] If there is
something inappropriate going on with a vmsish pragma and the return
value of the system() call, that's another place where something could
go wrong, but also as yet another wacky theory that I haven't been
able to prove.
Since no one else is reporting this failure, I will start looking at the
VMS specific code for implementing system() so see if I can find anything.
Unfortunately many other things in VMS can return same code, but so far,
that is the best theory I have seen.
I've attached a version of the test script that is slimmed down from
400+ lines to 99 lines but still produces the access violation.
Thanks, I will try that.
It consistently crashes when not run in debug, but only crashes
sometimes when I have it in the debugger.
I have it crashing on my assert now instead of the access violation.
My next plan is to put some code to walk that body linked list at
various places where the code implementing the system() call is writing
the status value to memory to see if the corruption can be detected.
The base of the body linked list is a off of the my_perl context variable.
[1] IPC::Cmd::_run does not quote arguments, so in its current form
it's not really suitable as a cross-platform way to run Perl
one-liners. For example, when it means to run:
perl -M100 -e1
Perl v1410065408.0.0 required--this is only v5.11.0, stopped.
BEGIN failed--compilation aborted.
%SYSTEM-F-ABORT, abort
it's actually running:
$ perl -M100 -e1
syntax error at -e line 0, near use 100 (
Execution of -e aborted due to compilation errors.
%SYSTEM-F-ABORT, abort
So the CPANPLUS::Dist test is not distinguishing between a syntax
error and a version check failure. I don't think it makes any
difference for the access violation, but it's something I noticed
while trying to pursue that.
That probably explains some of the failures besides the access
violation. The other is probably related to a sample file having a '~'
character in the name.
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
Craig A. Berry wrote: On May 3, 2009, at 9:20 PM, John E. Malmberg wrote: John E. Malmberg wrote: Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type) case SVt_PVMG: ... new_body_inline(new_body, new_type); new_type = SVt_PVMG, SVt_PVMG has a value of 7. new_body = 44. PL_Body_roots[sv_type] = 44. From the code, it looks like this was expected to contain a valid pointer. From looking at the source code, it appears that the linked list of bodies is corrupted. my_perl-Ibodyroots[7] has 44. Yes, I see the same thing. I have been looking at the S_more_bodies routine. Would it be practical to put an assert on for a pointer being added to the linked list with a value above 512? On VMS, the first page of memory is protected no access. I haven't had much time to poke at this, but I think an assert there would only help if the body is created with a bogus pointer in the SVt_PVMG slot rather than created with a good pointer that gets clobbered later, and I think the second explanation is more likely. I merely observe (without yet a chance fully to pursue) that 44 is a suspicious number on a couple of different fronts. Running with -Dm shows that various 44-byte chunks of memory get allocated, including arenas that are multiples of 44 in size, so if there is a legitimate size of 44 that is added to something that should be a good value but is actually NULL, that might be one explanation for where the bad smell is coming from. 44 / 0x2c is the value of SS$_ABORT, which is the return value of the system() call in IPC::Cmd::_run, which is called somewhere in the chain following from CPANPLUS::Dist::_resolve_prereqs.[1] If there is something inappropriate going on with a vmsish pragma and the return value of the system() call, that's another place where something could go wrong, but also as yet another wacky theory that I haven't been able to prove. The only way that I can see that being an issue is if the return value is ever stored in malloc()ed memory, and then either a buffer overrun of that storage, or that memory gets freed before the status value is written. Since no one else is reporting this failure, I will start looking at the VMS specific code for implementing system() so see if I can find anything. Unfortunately many other things in VMS can return same code, but so far, that is the best theory I have seen. If I put some additional checks in SV.c to walk that linked list each time that routine is called, I may be able to detect the corruption before the access violation takes place. With the amount of times that it gets called in perl, this may give us a break, unless it changes things enough to get hide of the access violation. I've attached a version of the test script that is slimmed down from 400+ lines to 99 lines but still produces the access violation. Thanks, I will try that. [1] IPC::Cmd::_run does not quote arguments, so in its current form it's not really suitable as a cross-platform way to run Perl one-liners. For example, when it means to run: perl -M100 -e1 Perl v1410065408.0.0 required--this is only v5.11.0, stopped. BEGIN failed--compilation aborted. %SYSTEM-F-ABORT, abort it's actually running: $ perl -M100 -e1 syntax error at -e line 0, near use 100 ( Execution of -e aborted due to compilation errors. %SYSTEM-F-ABORT, abort So the CPANPLUS::Dist test is not distinguishing between a syntax error and a version check failure. I don't think it makes any difference for the access violation, but it's something I noticed while trying to pursue that. That probably explains some of the failures besides the access violation. The other is probably related to a sample file having a '~' character in the name. -John wb8...@qsl.net Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
John E. Malmberg wrote:
John E. Malmberg wrote:
Nicholas Clark wrote:
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
I just started looking into a failure of 19_CPANPLUS-Dist. I have
not determined what exactly is wrong, and am out of time for the
moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real)
parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid
pointer.
From looking at the source code, it appears that the linked list of
bodies is corrupted. my_perl-Ibodyroots[7] has 44.
I have been looking at the S_more_bodies routine. Would it be practical
to put an assert on for a pointer being added to the linked list with a
value above 512? On VMS, the first page of memory is protected no access.
I put a modified test script at
http://eisner.encompasserve.org/~malmberg/perl/19_CPANPLUS-DIST.TXT
I commented out as much as I could and still reproduce the access violation.
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
John E. Malmberg wrote:
Nicholas Clark wrote:
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
I just started looking into a failure of 19_CPANPLUS-Dist. I have
not determined what exactly is wrong, and am out of time for the moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real)
parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid pointer.
From looking at the source code, it appears that the linked list of
bodies is corrupted. my_perl-Ibodyroots[7] has 44.
I have been looking at the S_more_bodies routine. Would it be practical
to put an assert on for a pointer being added to the linked list with a
value above 512? On VMS, the first page of memory is protected no access.
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
Nicholas Clark wrote:
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
I just started looking into a failure of 19_CPANPLUS-Dist. I have not
determined what exactly is wrong, and am out of time for the moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
000F9AB8
DBGPERLSHR SV Perl_sv_setsv_flags76204 AC88
001027E8
EAGLE search [-]sv.lis/window=10 73671
2 73667 /* We always allocated the full length item
with PURIFY.
To do this
2 73668we fake things so that arena is false for
all 16 type
s.. */
3 73669 if(new_type_details-arena) {
3 73670 /* This points to the start of the
allocated area.
*/
3 73671 new_body_inline(new_body, new_type);
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real) parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid pointer.
Looking at the source, the Macro PURIFY is not defined.
new_body_inline() was invoked there with the same arguments, yet here it
did not access violate.
Looking at sv-sv_any, it contains 0 at the time of the access violation.
At the time of the access violation, new_type_details-offset is 0.
If I set the breakpoints closer to where the access violation occurs, I
do not see an access violation. In the past, when that happens, it
indicates an uninitialized variable.
Regards,
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
Craig A. Berry wrote:
On Apr 27, 2009, at 8:40 AM, Nicholas Clark wrote:
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
I just started looking into a failure of 19_CPANPLUS-Dist. I have not
determined what exactly is wrong, and am out of time for the moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
000F9AB8
DBGPERLSHR SV Perl_sv_setsv_flags76204 AC88
001027E8
EAGLE search [-]sv.lis/window=10 73671
2 73667 /* We always allocated the full length item
with PURIFY.
To do this
2 73668we fake things so that arena is false for
all 16 type
s.. */
3 73669 if(new_type_details-arena) {
3 73670 /* This points to the start of the
allocated area.
*/
3 73671 new_body_inline(new_body, new_type);
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real)
parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
For me the access violation does not happen when running under the
debugger, where it would be easy to examine new_type. Without running
in debug, we see
ok 56 - Perl binary version too low
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000FA491, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image moduleroutine line rel PC abs PC
DBGPERLSHR SV Perl_sv_upgrade 86326 4641
000FA491
etc., as John reported. Note that a virtual address of 0x2c (decimal
44) is not a possible address.
Whereas running under the debugger we get:
ok 55 - Rebuilding trees
not ok 56 - Perl binary version too low
# Failed test 'Perl binary version too low'
# at [-.lib.cpanplus.t]19_cpanplus-dist.t line 358.
# got: '1'
# expected: ''
line 358 is:
is( !!$flag, !!$bool, $txt );
not ok 57 -Perl version not high enough
# Failed test ' Perl version not high enough'
# at [-.lib.cpanplus.t]19_cpanplus-dist.t line 232.
# ''
# doesn't match '(?-xism:needs perl version)'
ok 58 - Rebuilding trees
line 232 is:
sub { like( CPANPLUS::Error-stack_as_string,
qr/needs perl version/,
Perl version not high enough ) },
The debugger is likely to zero out uninitialized memory and do other
things that might protect the stack from corruption, so that may be a
partial explanation of the difference. It does look as though the
damage is being done at test 56 (or earlier) but doesn't show up until
test 58 unless you are running under the debug environment.
The particular expansion of the new_body_inline macro where the crash
occurs looks like:
3 86326 new_body_inline(new_body, new_type);
E do { void * * const r3wt = ( my_perl -
Ibody_roots ) [ new_type ] ; new_body = ( PTR_TBL_ENT_t * ) ( * ( (
Evoid * * ) ( r3wt ) ) ? * ( ( void * * ) ( r3wt ) ) :
S_more_bodies ( my_perl , new_type ) ) ; * ( r3wt ) = * ( void
E * * ) ( new_body ) ; } while ( 0 )
That's all the debugging time I have for now.
To catch the exception in the VMS debugger:
1. Use the Perl debugger to start the test.
2. After the Perl image has been activated, enter Control-Y, and then
type DEBUG to bring up the VMS debugger.
3. In the VMS Debugger, set break/exception, and then type go.
I use the Perl debugger in forked mode for X11 and also the VMS debugger
for X11 to keep the test I/O separate from the debugger IO.
-John
wb8...@qsl.net
Personal Opinion Only
[rt.cpan.org #45461] M::B ext.t needs fix to support VMS.
Module::Build needs a patch to get the last test to pass on VMS. https://rt.cpan.org/Ticket/Display.html?id=45461 -John wb8...@qsl.net Personal Opinion Only
Access violation in SV.C new_body_inline()
I just started looking into a failure of 19_CPANPLUS-Dist. I have not
determined what exactly is wrong, and am out of time for the moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
000F9AB8
DBGPERLSHR SV Perl_sv_setsv_flags76204 AC88
001027E8
DBGPERLSHR SV Perl_newSVsv 80243 00019E58
001119B8
DBGPERLSHR PP_HOT Perl_pp_aassign71335 533C
001F5B2C
DBGPERLSHR DUMP Perl_runops_debug81310 8794
001B9044
DBGPERLSHR PERL S_run_body 72774 4A78
000BC7C8
DBGPERLSHR PERL perl_run 72699 46C0
000BC410
Perl PERLMAIN main 70428 0204
00020204
Perl PERLMAIN __main 70377 00A0
000200A0
PTHREAD$RTL0 00057618
80E77618
PTHREAD$RTL0 00030444
80E50444
0 8037BCE4
8037BCE4
EAGLE search [-]sv.lis/window=10 73671
2 73667 /* We always allocated the full length item
with PURIFY.
To do this
2 73668we fake things so that arena is false for
all 16 type
s.. */
3 73669 if(new_type_details-arena) {
3 73670 /* This points to the start of the
allocated area.
*/
3 73671 new_body_inline(new_body, new_type);
EAGLE MCR Sys$Disk:[]Perl.EXE -V
Summary of my perl5 (revision 5 version 11 subversion 0) configuration:
Snapshot of: 30a06a3af12bb1237a004c2795d506c231bc6ea5
Platform:
osname=VMS, osvers=V8.3, archname=VMS_AXP-ithread
uname='VMS eagle V8.3 AlphaServer DS10 617 MHz'
config_args='-Dusevmsdebug -Dusedevel -Duseithreads
-Duselargefiles -Dcf_e
mail=SYSTEM -de'
hint=none, useposix=false, d_sigaction=define
useithreads=define, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=undef, bincompat5005=undef
Compiler:
cc='CC/DECC', ccflags
='/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.ob
j /NOANSI_ALIAS/float=ieee/ieee=denorm/Define=_USE_STD_STAT=1',
optimize='/List/Debug/NoOpt',
cppflags='undef'
ccversion='70190015', gccversion='', gccosandvers='undef'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize
=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='Link/nodebug', ldflags ='/Debug/Trace/Map'
libpth=/sys$share /sys$library
libs=
perllibs=
libc=(DECCRTL), so=exe, useshrplib=true, libperl=undef
gnulibc_version='undef'
Dynamic Linking:
dlsrc=dl_vms.c, dlext=exe, d_dlsymun=undef, ccdlflags=''
cccdlflags='', lddlflags='/Share'
Characteristics of this PERLSHR image:
Compile-time options: DEBUGGING DECCRTL_SOCKETS MULTIPLICITY
PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP PERL_TRACK_MEMPOOL USE_IEEE
USE_ITHREADS USE_LARGE_FILES USE_PERLIO
USE_REENTRANT_API VMS_DO_SOCKETS
Built under VMS
Compiled at Apr 25 2009 22:36:36
%ENV:
PERL5LIB=PROJECT_ROOT:[PERL-BLEAD.lib]|/project_root/perl-blead/lib/cpanplu
s/t/../lib|/project_root/perl-blead/lib/cpanplus/t/inc|PROJECT_ROOT:[PERL-BLEAD.
lib]|PROJECT_ROOT:[PERL-BLEAD.t]
PERL5_CPANPLUS_IS_RUNNING=1470086
PERL5_CPANPLUS_IS_VERSION=0.86_06
PERLDB_PIDS=XXX
PERLSHR=PERL_ROOT:[00]PERLSHR.EXE
PERL_BUILD_ROOT=disk$bigdisk:[project_root.perl-blead.]
PERL_CORE=1
PERL_DESTRUCT_LEVEL=2
PERL_ROOT=SYS$SYSDEVICE:[VMS$COMMON.PERL5_8_6.]
@INC:
/PROJECT_ROOT/PERL-BLEAD/lib
/project_root/perl-blead/lib/cpanplus/t/../lib
/project_root/perl-blead/lib/cpanplus/t/inc
/PROJECT_ROOT/PERL-BLEAD/lib
/PROJECT_ROOT/PERL-BLEAD/t
perl_root:[lib.site_perl.VMS_AXP]
perl_root:[lib.site_perl]
perl_root:[lib.VMS_AXP.5_11_0]
perl_root:[lib]
.
-John
wb8...@qsl.net
Personal Opinion Only
blead@09-04-25.23:16:08 t/test - Hack for VMS pipe bug.
The VMS pipe bug inserts blank lines in places that can prevent the
leader from being seen.
So on the leader line, read in the rest of the line.
Related VMS TODO: The VMS/test.com procedure is passing an uppercase
path specification instead of exact case or forced to lowercase.
This can cause the t/test. to incorrectly issue the diagnostic:
FAILED--unexpected output at test $next at times on VMS.
-John
wb8...@qsl.net
Personal Opinion Only
--- /rsync_root/perl/t/TEST Wed Mar 25 12:50:09 2009
+++ t/TEST Sun Apr 26 20:38:43 2009
@@ -338,6 +338,14 @@
my %todo;
while (RESULTS) {
next if /^\s*$/; # skip blank lines
+ if (/^1..$/ ($^O eq 'VMS')) {
+ # VMS pipe bug inserts blank lines.
+ my $l2 = RESULTS;
+ if ($l2 =~ /^\s*$/) {
+ $l2 = RESULTS;
+ }
+ $_ = '1..' . $l2;
+ }
if ($::verbose) {
print $_;
}
Re: Existance of BIN logical interferes with MakeMaker tests.
Craig A. Berry wrote: On Apr 10, 2009, at 9:55 PM, John E. Malmberg wrote: [Dropping some names off the distribution as similar information has been sent to them] John E. Malmberg wrote: Craig A. Berry wrote: On Apr 10, 2009, at 4:20 PM, Michael G Schwern wrote: GNV should not be assigning that logical name and later versions than the one they've got there don't. It should be safe just to deassign it. $ @gnv$gnu:[lib]gnv_setup.com $ show log bin BIN = GNV$GNU:[BIN] (LNM$PROCESS_TABLE) $ deassign bin $ sh log bin %SHOW-S-NOTRAN, no translation for logical name BIN I was not aware of a later version than what I put on Encompasserve. While I submitted the code to the maintainer for rebuilding the kit, I had not heard of any new releases. Encompasserve.org is running GNV 2.1-2 + patches that have been submitted to HP. The GNV kit at the HP web site is still 2.1-2. The version of GNV on Encompasserve puts the BIN logical in the process table instead of the system table as the HP version did at the time I installed it, so deassigning it to run Perl is the thing to do. I just did a quick check. With out the logical name BIN defined there are a number of things that will not work. This is because with out that logical name, the CRTL redirects /bin to be /SYS$SYSTEM Eisner may have the current version of GNV installed, but it does not appear to have the current version of the set-up command procedure. This is Eisner: $ search gnv$gnu:[lib]gnv_setup.com bin $! Add GNU:[BIN] to path if it's not already there. $ call add_path dcl$path gnv$gnu:[bin] $ call add_path vaxc$path gnv$gnu:[bin] $! Some hacks: Logicals needed until the binaries in GNV can be fixed. $if f$trnlnm(BIN) .eqs. $ define bin gnv$gnu:[bin] $ bash :== $gnv$gnu:[bin]bash Here is one of my systems with GNV v2.1-2: $ search DISK$ALPHASYS:[SYS0.SYSCOMMON.GNV.LIB]GNV_SETUP.COM bin $! Add GNU:[BIN] to path if it's not already there. $ call add_path dcl$path gnu:[bin] $ call add_path vaxc$path gnu:[bin] $ bash :== $gnu:[bin]bash As you can see, there is no longer a logical named bin, nor is there a gnv$gnu logical. Nor, as I understand it, is there any reason to have those as it's all done by mount points now. On the other hand, I'm pretty sure you're the one who told me that, so maybe I'm missing something. The mount points are only visible to C programs in a UNIX format when the DECC$POSIX_COMPLIANT_PATHNAMES option is active. This option can not be used for most C programs because RMS does not support translating logical names. Until that update to RMS is released either as an ECO or a new version of VMS, effectively the POSIX_COMPLIANT_PATHNAMES modes are not usable. The mount point as installed by GNV 2.1-1 also are backwards of what they should be. It can cause an infinite loop in walking directories. The installation on Encompasserve has also corrected this issue. The GNV$GNU is a officially registered logical name for the GNV product. It is a violation of long standing VMS standards to have a layered product define a logical name in the system table with out having a registered prefix. The installation on Encompasserve also does not define SYS$POSIX_ROOT in the system table on GNV startup as it globally affects all programs. Instead sys$posix_root is now defined in the process table, which is also a hack. A patch has been submitted to HP to remove that requirement. Removing the BIN and SYS$POSIX_ROOT logical name left behind by GNV_SETUP.COM will require relinking all the modules, which requires changing the link procedure. I have not had the time to make those changes. My plan is to use the existing GNV tools to run build the current versions of the utilities and package them up in PCSI kits corresponding to how they are packaged on UNIX, so eventually the GNV PCSI kit will mainly be a master kit that installs the selected components. Regards, -John wb8...@qsl.net Personal Opinion Only
Re: Existance of BIN logical interferes with MakeMaker tests.
[Dropping some names off the distribution as similar information has been sent to them] John E. Malmberg wrote: Craig A. Berry wrote: On Apr 10, 2009, at 4:20 PM, Michael G Schwern wrote: GNV should not be assigning that logical name and later versions than the one they've got there don't. It should be safe just to deassign it. $ @gnv$gnu:[lib]gnv_setup.com $ show log bin BIN = GNV$GNU:[BIN] (LNM$PROCESS_TABLE) $ deassign bin $ sh log bin %SHOW-S-NOTRAN, no translation for logical name BIN I was not aware of a later version than what I put on Encompasserve. While I submitted the code to the maintainer for rebuilding the kit, I had not heard of any new releases. Encompasserve.org is running GNV 2.1-2 + patches that have been submitted to HP. The GNV kit at the HP web site is still 2.1-2. The version of GNV on Encompasserve puts the BIN logical in the process table instead of the system table as the HP version did at the time I installed it, so deassigning it to run Perl is the thing to do. I just did a quick check. With out the logical name BIN defined there are a number of things that will not work. This is because with out that logical name, the CRTL redirects /bin to be /SYS$SYSTEM Everything has to be relinked with a variant of the lib$initialize code that I added to GNU TAR 1.19 in order to fix that. Once we can get the patches that I submitted to Perl in place, I plan to start looking at GIT, curl, and fixing up GNV. I just have not had as much time to do this as I use to. There is a porting_to_vms notes conference on Encompasserve.org where anyone who wants to help can join in. Regards, -John wb8...@qsl.net Personal Opinion Only
Re: Existance of BIN logical interferes with MakeMaker tests.
Craig A. Berry wrote:
On Apr 10, 2009, at 4:20 PM, Michael G Schwern wrote:
GNV should not be assigning that logical name and later versions than
the one they've got there don't. It should be safe just to deassign it.
$ @gnv$gnu:[lib]gnv_setup.com
$ show log bin
BIN = GNV$GNU:[BIN] (LNM$PROCESS_TABLE)
$ deassign bin
$ sh log bin
%SHOW-S-NOTRAN, no translation for logical name BIN
I was not aware of a later version than what I put on Encompasserve.
While I submitted the code to the maintainer for rebuilding the kit, I
had not heard of any new releases.
The version of GNV on Encompasserve puts the BIN logical in the process
table instead of the system table as the HP version did at the time I
installed it, so deassigning it to run Perl is the thing to do.
I will have to go to the HP web site to get a later GNV to see if they
put in all the changes I submitted.
I don't think there's much MakeMaker can or should do about it unless
you want to put C$ENV{bin} = undef in a BEGIN block or something.
I do not think you want to do that. Won't that delete the first logical
name BIN in the default logical search list, if the person has
sufficient privilege?
We really need logical name handling as part of PERL on VMS so that
tests can work around these issues.
The best generic work around that I can think of is to check to see if
$ENV{bin} exists on VMS and if so create a new defintion that is needed
for the test.
Unfortunately without true logical name support, there is no generic way
to clean it up inside of Perl.
Regards,
-John
wb8...@qsl.net
Personal Opinion Only
Re: Better way to handle Unix compatibility modes must be found
Michael G Schwern wrote: John E. Malmberg wrote: It is only the case where something is building a VMS specific Make script or building a DCL command file that a filename needs to specifically be converted to VMS path syntax. Ok, then build it into the MakeMaker File::Spec overrides and use them. The File::Spec overrides appear to only exist in MM_VMS. I am not sure how to call them outside of the class for all platforms. And this only affects the two test programs. The additional VMS specific check in patch submitted to lib/ExtUtils/install.pm is that when VMS is in the extended character set mode, File::Spec::catdir() operates properly. In the traditional VMS mode, catdir() does work correctly in the case where install.pm calls it, and there may be a few programs out there that depend on it being broken so the behavior has not been changed. In efs mode, since catdir() will work correctly, the work-around for the traditional bug will cause an incorrectly created filename, so it must not be used. install.pm may be one of the few cases that this issue shows up. Calling the MakeMaker File::Spec routines will not fix this issue in this case, because the calling program has to know how to pass the parameters. The checks for UNIX mode and case preserved are not used in install.pm and can be removed from the code. For the test inst.t and inst_prefix.t programs, I am not sure how to get them to use the MM_VMS:: instead of File::Spec without causing just as much disruption to the code as the additional vmsify and vmspath. Regards, -John wb8...@qsl.net Personal Opinion Only
Re: Better way to handle Unix compatibility modes must be found
Michael G Schwern wrote:
John E. Malmberg wrote:
Are you going to have time to look at the patches that I submitted to
MakeMaker and Test::Simple?
These are to support VMS when the DECC$FILENAME_UNIX_REPORT and
DECC$EFS_CHARSET and related options are active.
These options make Perl on VMS look more like Unix, including returning
filenames in Unix syntax. Path tools has already been updated to work
in this mode.
I had a look at this, and I can't apply it. It was bad enough having special
case code for VMS, now there's three different styles of VMS to be considered.
Yes there are three major sets:
1. Traditional mode which is limited in the character set available,
which includes several serious bugs in the conversion of Unix format
file specifications to and from VMS format. These bugs can not be fixed
in this mode because other programs may depend on them being present.
In several cases, the Unix file specifications produced are invalid and
can not be used, except for special VMS code that has been added to deal
with the bugs.
Some of the bugs in the traditional mode are from the assumption that
the equations ($path == vmsify(unixify($path))) and ($path ==
unixify(vmsify($path))) will always evaluate to true.
This is not the case on VMS and never has been the case for all file
specifications. The file $foo that results from $foo =
vmsify(unixify($bar)) may not even resolve to the same directory as
$bar, let alone the same file.
In short, you only want to vmsify or unixify a filespec once, just
before it is used to access a path or a file. You can not unixify a VMS
file specification with the expectation that you can vmsify it back to
the original file or the reverse.
That has never fully worked, and can not be made to fully work.
In order to use the Traditional VMS mode, Perl programs usually need to
also have VMS specific code in them.
2. Extended character set, VMS format, which requires that the bugs in
the Unix to VMS conversions not be present.
This is because with the restricted character set, the illegal Unix
names were obvious and could be handled, but with the extended character
set, those Unix names could be valid, even though they are usually not.
This exposes many cases where vmsify(unixify) or unixify(vmsify) was
being used and totally failing, since files that were previously ignored
were now being used.
A side effect of this is that VMS can preserve the case of the filename
similar to how Windows does.
Many Perl programs will now just work on VMS in this mode, unless they
have some explicit UNIX requirement.
3. Unix compatibility mode. This is where VMS both case preserves the
results, but also the library routines will returns results
There is also a mode where the VMS C library will not accept VMS syntax
filenames, but assumes Unix. I have not tried to get that mode to work.
While the Unix compatibility is not perfect, it is good enough for many
Perl scripts written with only UNIX in mind to work on VMS with zero
modifications.
While there are three main modes, there many feature settings that
control them, and each of those modes are a result of preset combinations.
It is not the case that all perl programs need to check the mode that
VMS is in. It is only a small set of perl programs.
1. Test programs that need to explicitly know what syntax a filename is
going to be.
2. Library routines that have to support the traditional VMS mode, and
should also work in the two other modes.
3. Library routines that generate scripts/makefiles or native command lines.
It the future, Perl on VMS will be optionally supporting Unix shells
like bash as a default instead of just DCL.
Here's the mass of detection code:
use VMS::Feature;
my $vms_unix_rpt = VMS::Feature::current(filename_unix_report);
my $vms_efs = VMS::Feature::current(efs_charset);
my $vms_case = VMS::Feature::current(efs_case_preserve);
$Is{VMS_mode} = 0 if $vms_unix_rpt;
$Is{VMS_unix} = 1 if $vms_unix_rpt;
$Is{VMS_lc}= 0 if $vms_case;
$Is{VMS_noefs} = 0 if $vms_efs;
That mercifully doesn't include the work around if VMS::Feature isn't there.
There's no way to expect Perl programmers to stick all that in their code just
to accommodate VMS.
But this diff here illustrates the real problem:
-is( $mm-{INSTALLVENDORMAN1DIR}, File::Spec-catdir('foo','bar'),
+my $expect = File::Spec-catdir('foo','bar');
+$expect = VMS::Filespec::vmspath($expect) if $Is_VMS;
+is( $mm-{INSTALLVENDORMAN1DIR}, $expect,
'installvendorman1dir (in %Config) not modified' );
Now every call to File::Spec, which is supposed to generate a portable path,
has to have extra code tacked onto the end to do more work. If that's
necessary then File::Spec::VMS should be doing it.
File::Spec::VMS traditionally has not generated a portable path. It
only does that now
Re: [patch@35055] taint.t minor patch for VMS
Craig A. Berry wrote:
On Dec 9, 2008, at 10:30 PM, John E. Malmberg wrote:
Tainting DCL$PATH has no effect on Perl on VMS.
But DCL$PATH will be used by DCL after invoking system() or backticks in
a manner very similar to how PATH is used on other systems. Tainting is
specifically designed to handle just such interactions with the outside
world.
That logical name is not currently used internal to Perl so it never
gets checked to see if it is tainted.
Opps, I only checked VMS.c
Check again:
$ search *.c dcl$path
**
D0:[CRAIG.perl]mg.c;1
if (s klen == 8 strEQ(ptr, DCL$PATH)) {
do { /* DCL$PATH may be a search list */
**
D0:[CRAIG.perl]taint.c;1
char name[10 + TYPE_DIGITS(int)] = DCL$PATH;
len = my_sprintf(name,DCL$PATH;%d, i);
taint_proper(Insecure %s%s, $ENV{DCL$PATH});
taint_proper(Insecure directory in %s%s, $ENV{DCL$PATH});
**
D0:[CRAIG.perl]util.c;1
(!hasdir my_trnlnm(DCL$PATH,tmpbuf,idx++)) )
It is still a TODO problem, with scratch directory set to world
writeable, those two tests cases are failing.
-John
[EMAIL PROTECTED]
Personal Opinion Only
[patch@35055] taint.t minor patch for VMS
Tainting DCL$PATH has no effect on Perl on VMS.
That logical name is not currently used internal to Perl so it never
gets checked to see if it is tainted.
So even when the /tmp directory exists and is world writable, these
tests will not pass.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/t/op/taint.t Wed Dec 3 03:23:35 2008
+++ t/op/taint.tTue Dec 9 22:21:54 2008
@@ -219,8 +219,13 @@
test eval { `$echo 1` } eq '';
test $@ =~ /^Insecure \$ENV{DCL\$PATH}/, $@;
SKIP: {
-skip q[can't find world-writeable directory to test DCL$PATH], 2
- unless $tmp;
+ # DCL$PATH is not used by PERL to launch programs and is not
+ # specifically checked, so tainting it is not going to be
+ # noticed. So for now, this test is not valid.
+
+ skip q[TODO DCL$PATH tainting is not checked by perl], 2;
+#skip q[can't find world-writeable directory to test DCL$PATH], 2
+# unless $tmp;
$ENV{'DCL$PATH'} = $tmp;
test eval { `$echo 1` } eq '';
Re: [patch@35050] replace pathify_dirspec in VMS with new version
John E. Malmberg wrote: The mp_do_pathify_dirspec needed enhancements to more accurately parse VMS file specifications, and also to handle UNIX file specifications the same way that mp_do_tovmspath() does. It was simpler to replace than to try to modify the existing routine. In addition this is the start of fixing issues where routines can be called with a null thread context, by removing the thread context where it is not needed. More patches will be following this. An additional note, this patch may cause some tests in vmsfspec.t to fail. That is because the old behavior of pathfiy_dirspec() was inconsistent with vmsify(). I am working on a new version of vmssfspec.t that handles both the traditional mode of perl and with the decc$efs_charset / decc$filename_unix_report modes activated. -John [EMAIL PROTECTED] Personal Opinion Only
[patch@35055] VMS parsing not handling no-priv cases
The VMS parsing routines were failing on files that the process
currently did not have access to, instead of falling back to a syntax
only check.
We may want to consider always falling back to a syntax only check as
there may be more non-fatal return codes of these type.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /ref2_root/perl/vms/vms.c Sun Dec 7 08:47:36 2008
+++ vms/vms.c Sun Dec 7 08:53:17 2008
@@ -5478,10 +5478,13 @@
/* Could not find the file, try as syntax only if error is not fatal */
rms_set_nam_nop(mynam, NAM$M_SYNCHK);
-if (retsts == RMS$_DNF || retsts == RMS$_DIR || retsts == RMS$_DEV) {
+if (retsts == RMS$_DNF ||
+ retsts == RMS$_DIR ||
+ retsts == RMS$_DEV ||
+ retsts == RMS$_PRV) {
retsts = sys$parse(myfab,0,0);
if (retsts STS$K_SUCCESS) goto expanded;
-}
+}
/* Still could not parse the file specification */
/*--*/
@@ -6047,7 +6050,9 @@
for (cp = trndir; *cp; cp++)
if (islower(*cp)) { haslower = 1; break; }
if (!((sts = sys$parse(dirfab)) STS$K_SUCCESS)) {
-if ((dirfab.fab$l_sts == RMS$_DIR) || (dirfab.fab$l_sts == RMS$_DNF)) {
+if ((dirfab.fab$l_sts == RMS$_DIR) ||
+(dirfab.fab$l_sts == RMS$_DNF) ||
+(dirfab.fab$l_sts == RMS$_PRV)) {
rms_set_nam_nop(dirnam, NAM$M_SYNCHK);
sts = sys$parse(dirfab) STS$K_SUCCESS;
}
[patch@35055] vms.c unixify refactor
This patch makes a version of unixify available for calling with out an
implicit context, which is needed for threaded perl as several routines
do not have a thread context.
This is the second of a multi-part conversion to remove access
violations when internal perl warning and error routines, and memory
allocation routines are called with a null pointer for the implicit context.
By removing the implicit context from these routines, it will cause a
compile time error on threaded perl should one of the affected routines
sneak back into this code.
Patches to do:
* Refactor tounixpath, (unixpath)
* Refactor fileify_dirspec (fileify)
* Refactor tovmsspec, (vmsify)
* Refactor rmsexpand
* Refactor all cases where a implicit context is not needed
and fix cases where a null context is present not to call
internal perl routines that will access violate.
* fgetname needs a wrapper, it is not returning the correct
names when DECC$FILENAME_UNIX_REPORT is enabled.
This is all needed for me to proceed with the testing of VMS perl in a
UNIX compatible mode. Currently most of the tests are passing.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /ref3_root/perl/vms/vms.c Sun Dec 7 09:19:05 2008
+++ vms/vms.c Sun Dec 7 09:35:46 2008
@@ -296,6 +296,8 @@
static char *mp_do_tounixspec(pTHX_ const char *, char *, int, int *);
static char *mp_do_pathify_dirspec(pTHX_ const char *dir,char *buf, int ts,
int *);
+static char * int_tounixspec(const char *spec, char *buf, int * utf8_fl);
+
/* see system service docs for $TRNLNM -- NOT the same as LNM$_MAX_INDEX */
#define PERL_LNM_MAX_ALLOWED_INDEX 127
@@ -6733,300 +6735,367 @@
char *Perl_pathify_dirspec_utf8_ts(pTHX_ const char *dir, char *buf, int
*utf8_fl)
{ return do_pathify_dirspec(dir,buf,1,utf8_fl); }
+/* Internal tounixspec routine that does not use a thread context */
+static char *
+int_tounixspec(const char *spec, char *buf, int * utf8_fl) {
-/*{{{ char *tounixspec[_ts](char *spec, char *buf, int *)*/
-static char *mp_do_tounixspec(pTHX_ const char *spec, char *buf, int ts, int *
utf8_fl)
-{
- static char __tounixspec_retbuf[VMS_MAXRSS];
- char *dirend, *rslt, *cp1, *cp3, *tmp;
- const char *cp2;
- int devlen, dirlen, retlen = VMS_MAXRSS;
- int expand = 1; /* guarantee room for leading and trailing slashes */
- unsigned short int trnlnm_iter_count;
- int cmp_rslt;
- if (utf8_fl != NULL)
-*utf8_fl = 0;
-
- if (spec == NULL) return NULL;
- if (strlen(spec) (VMS_MAXRSS-1)) return NULL;
- if (buf) rslt = buf;
- else if (ts) {
-Newx(rslt, VMS_MAXRSS, char);
- }
- else rslt = __tounixspec_retbuf;
+char *dirend, *cp1, *cp3, *tmp;
+const char *cp2;
+int devlen, dirlen, retlen = VMS_MAXRSS;
+int expand = 1; /* guarantee room for leading and trailing slashes */
+unsigned short int trnlnm_iter_count;
+int cmp_rslt;
+if (utf8_fl != NULL)
+*utf8_fl = 0;
- /* New VMS specific format needs translation
- * glob passes filenames with trailing '\n' and expects this preserved.
- */
- if (decc_posix_compliant_pathnames) {
-if (strncmp(spec, \^UP^, 5) == 0) {
- char * uspec;
- char *tunix;
- int tunix_len;
- int nl_flag;
-
- tunix = PerlMem_malloc(VMS_MAXRSS);
- if (tunix == NULL) _ckvmssts(SS$_INSFMEM);
- strcpy(tunix, spec);
- tunix_len = strlen(tunix);
- nl_flag = 0;
- if (tunix[tunix_len - 1] == '\n') {
- tunix[tunix_len - 1] = '\';
- tunix[tunix_len] = '\0';
- tunix_len--;
- nl_flag = 1;
- }
- uspec = decc$translate_vms(tunix);
- PerlMem_free(tunix);
- if ((int)uspec 0) {
- strcpy(rslt,uspec);
- if (nl_flag) {
- strcat(rslt,\n);
- }
- else {
- /* If we can not translate it, makemaker wants as-is */
- strcpy(rslt, spec);
- }
- return rslt;
- }
+if (vms_debug_fileify) {
+if (spec == NULL)
+fprintf(stderr, int_tounixspec: spec = NULL\n);
+else
+fprintf(stderr, int_tounixspec: spec = %s\n, spec);
+}
+
+if (spec == NULL) {
+set_errno(EINVAL);
+set_vaxc_errno(SS$_BADPARAM);
+return NULL;
+}
+if (strlen(spec) (VMS_MAXRSS-1)) {
+set_errno(E2BIG);
+set_vaxc_errno(SS$_BUFFEROVF);
+return NULL;
}
- }
- cmp_rslt = 0; /* Presume VMS */
- cp1 = strchr(spec, '/');
- if (cp1 == NULL)
-cmp_rslt = 0;
+/* New VMS specific format needs translation
+ * glob passes filenames with trailing '\n' and expects this preserved.
+ */
+if (decc_posix_compliant_pathnames) {
+if (strncmp(spec, \^UP^, 5) == 0) {
+char * uspec;
+char *tunix;
+int tunix_len;
+int nl_flag;
+
+tunix = PerlMem_malloc(VMS_MAXRSS);
+if (tunix == NULL)
+_ckvmssts_noperl(SS$_INSFMEM);
+strcpy(tunix, spec);
+
Re: [patch@35050] replace pathify_dirspec in VMS with new version
Craig A. Berry wrote:
On Dec 7, 2008, at 12:46 PM, John E. Malmberg wrote:
Point taken,
Attached is vms/ext/filespec.t that changes those tests to be passing.
The documentation for VMS::Filespec::pathify says, the file type and
version, if specified, must be .DIR;1. For compatibility with Unix
usage, the type and version may also be omitted. The tests have
enforced this behavior since before 5.004. You're proposing to change
the behavior so that a file type that is not .DIR is no longer
considered a file type at all and the dot would then be considered part
of the filename rather than the start of the type field. That could
easily break existing code and doesn't seem to me like the way to go.
This is for UNIX format file specifications, which normally should not
have a .dir on them when they are directories.
The new behavior is not inconsistent with the existing documentation,
except that the old routine does not work for EFS characters.
Now if the dot is escaped and is thus unambiguously just an actual dot
rather than a directory or file type delimiter that's a different
story. We should support and test for those cases, something like:
__path_^.actualdot pathify __path_.actualdot/
The '^' escape character is only present on VMS format file
specifications. With out any directory delimiter characters present,
pathify assumes that this is a UNIX directory.
With a Unix directory syntax if .DIR is not present, the behavior of
pathify would normally to be just put a '/' on the specification.
Removing the .dir is needed because it may be present.
The following demonstrates the existing behavior is inconsistent:
$ perl -v
This is perl, v5.10.0 built for VMS_AXP
$ perl -e print VMS::Filespec::vmsify('foo/bar./')
[.foo.bar_]
$
$ perl -e print VMS::Filespec::vmspath('foo/bar.')
$
[Nothing output]
Those two sample one liners should have produced the same output.
$ define decc$efs_charset ENABLE
$ perl -e print VMS::Filespec::vmsify('foo/bar./')
[.foo.bar^.]
$ perl -e print VMS::Filespec::vmspath('foo/bar.')
$
[Nothing output]
As should these two examples.
So while it is change in behavior, the older tested behavior appears to
be incorrect as it will cause file specifications that are accepted in
other routines to be rejected.
I do not think this would be noticed in existing programs other than the
test routines because such file specifications are rare on a VMS system,
and that if someone had encountered one of them, they would have had to
modify their perl program to not use pathify, unixpath, or vmspath.
-John
[EMAIL PROTECTED]
Personal Opinion Only
[patch@35055] vms.c vmsify refactor
This patch makes a version of vmsify and vmspath available for calling
with out an implicit context, which is needed for threaded perl as
several routines do not have or need an implicit context.
This is the fourth of a multi-part conversion to remove access
violations when internal perl warning and error routines, and memory
allocation routines are called with a null pointer for the implicit context.
By removing the implicit context from these routines, it will cause a
compile time error on threaded perl should one of the affected routines
sneak back into this code.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /ref5_root/perl/vms/vms.c Sun Dec 7 14:10:15 2008
+++ vms/vms.c Sun Dec 7 15:56:16 2008
@@ -296,7 +296,10 @@
static char *mp_do_tounixspec(pTHX_ const char *, char *, int, int *);
static char *mp_do_pathify_dirspec(pTHX_ const char *dir,char *buf, int ts,
int *);
+static char *int_tovmsspec
+ (const char *path, char *buf, int dir_flag, int * utf8_flag);
static char * int_tounixspec(const char *spec, char *buf, int * utf8_fl);
+static char * int_tovmspath(const char *path, char *buf, int * utf8_fl);
/* see system service docs for $TRNLNM -- NOT the same as LNM$_MAX_INDEX */
#define PERL_LNM_MAX_ALLOWED_INDEX 127
@@ -8107,58 +8110,65 @@
}
+
/*{{{ char *tovmsspec[_ts](char *path, char *buf, int * utf8_flag)*/
-static char *mp_do_tovmsspec
- (pTHX_ const char *path, char *buf, int ts, int dir_flag, int * utf8_flag) {
- static char __tovmsspec_retbuf[VMS_MAXRSS];
- char *rslt, *dirend;
- char *lastdot;
- char *vms_delim;
- register char *cp1;
- const char *cp2;
- unsigned long int infront = 0, hasdir = 1;
- int rslt_len;
- int no_type_seen;
- char * v_spec, * r_spec, * d_spec, * n_spec, * e_spec, * vs_spec;
- int sts, v_len, r_len, d_len, n_len, e_len, vs_len;
-
- if (path == NULL) return NULL;
- rslt_len = VMS_MAXRSS-1;
- if (buf) rslt = buf;
- else if (ts) Newx(rslt, VMS_MAXRSS, char);
- else rslt = __tovmsspec_retbuf;
-
- /* '.' and '..' are [] and [-] for a quick check */
- if (path[0] == '.') {
-if (path[1] == '\0') {
- strcpy(rslt,[]);
- if (utf8_flag != NULL)
- *utf8_flag = 0;
- return rslt;
+static char *int_tovmsspec
+ (const char *path, char *buf, int dir_flag, int * utf8_flag) {
+char *dirend;
+char *lastdot;
+char *vms_delim;
+register char *cp1;
+const char *cp2;
+unsigned long int infront = 0, hasdir = 1;
+int rslt_len;
+int no_type_seen;
+char * v_spec, * r_spec, * d_spec, * n_spec, * e_spec, * vs_spec;
+int sts, v_len, r_len, d_len, n_len, e_len, vs_len;
+
+if (vms_debug_fileify) {
+if (path == NULL)
+fprintf(stderr, int_tovmsspec: path = NULL\n);
+else
+fprintf(stderr, int_tovmsspec: path = %s\n, path);
}
-else {
- if (path[1] == '.' path[2] == '\0') {
- strcpy(rslt,[-]);
- if (utf8_flag != NULL)
- *utf8_flag = 0;
- return rslt;
- }
+
+if (path == NULL) {
+set_errno(EINVAL);
+set_vaxc_errno(SS$_BADPARAM);
+return NULL;
}
- }
+rslt_len = VMS_MAXRSS-1;
- /* Posix specifications are now a native VMS format */
- /*--*/
+/* '.' and '..' are [] and [-] for a quick check */
+if (path[0] == '.') {
+if (path[1] == '\0') {
+strcpy(buf, []);
+if (utf8_flag != NULL)
+*utf8_flag = 0;
+return buf;
+} else {
+if (path[1] == '.' path[2] == '\0') {
+strcpy(buf, [-]);
+if (utf8_flag != NULL)
+*utf8_flag = 0;
+return buf;
+}
+}
+}
+
+ /* Posix specifications are now a native VMS format */
+/*--*/
#if __CRTL_VER = 8020 !defined(__VAX)
- if (decc_posix_compliant_pathnames) {
-if (strncmp(path,\^UP^,5) == 0) {
- posix_to_vmsspec_hardway(rslt, rslt_len, path, dir_flag, utf8_flag);
- return rslt;
+if (decc_posix_compliant_pathnames) {
+if (strncmp(path,\^UP^,5) == 0) {
+posix_to_vmsspec_hardway(buf, rslt_len, path, dir_flag, utf8_flag);
+return buf;
+}
}
- }
#endif
- /* This is really the only way to see if this is already in VMS format */
- sts = vms_split_path
+/* This is really the only way to see if this is already in VMS format */
+sts = vms_split_path
(path,
v_spec,
v_len,
@@ -8172,7 +8182,7 @@
e_len,
vs_spec,
vs_len);
- if (sts == 0) {
+if (sts == 0) {
/* FIX-ME - If dir_flag is non-zero, then this is a mp_do_vmspath()
replacement, because the above parse just took care of most of
what is needed to do vmspath when the specification is already
@@ -8183,13 +8193,17 @@
the result.
*/
-/* If VMS
[patch@35055] vms.c fileify refactor
This patch makes a version of fileify available for calling with out an
implicit context, which is needed for threaded perl as several routines
do not have or need an implicit context.
This is the fifth of a multi-part conversion to remove access violations
when internal perl warning and error routines, and memory allocation
routines are called with a null pointer for the implicit context.
By removing the implicit context from these routines, it will cause a
compile time error on threaded perl should one of the affected routines
sneak back into this code.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /ref6_root/perl/vms/vms.c Sun Dec 7 16:34:04 2008
+++ vms/vms.c Sun Dec 7 16:43:36 2008
@@ -298,6 +298,7 @@
static char *int_tovmsspec
(const char *path, char *buf, int dir_flag, int * utf8_flag);
+static char * int_fileify_dirspec(const char *dir, char *buf, int *utf8_fl);
static char * int_tounixspec(const char *spec, char *buf, int * utf8_fl);
static char * int_tovmspath(const char *path, char *buf, int * utf8_fl);
@@ -5792,50 +5793,55 @@
** found in the Perl standard distribution.
*/
-/*{{{ char *fileify_dirspec[_ts](char *dir, char *buf, int * utf8_fl)*/
-static char *mp_do_fileify_dirspec(pTHX_ const char *dir,char *buf,int ts, int
*utf8_fl)
-{
-static char __fileify_retbuf[VMS_MAXRSS];
+static char *
+int_fileify_dirspec(const char *dir, char *buf, int *utf8_fl) {
+
unsigned long int dirlen, retlen, addmfd = 0, hasfilename = 0;
-char *retspec, *cp1, *cp2, *lastdir;
+char *cp1, *cp2, *lastdir;
char *trndir, *vmsdir;
unsigned short int trnlnm_iter_count;
int sts;
if (utf8_fl != NULL)
- *utf8_fl = 0;
+*utf8_fl = 0;
if (!dir || !*dir) {
- set_errno(EINVAL); set_vaxc_errno(SS$_BADPARAM); return NULL;
+set_errno(EINVAL);
+set_vaxc_errno(SS$_BADPARAM);
+return NULL;
}
dirlen = strlen(dir);
-while (dirlen dir[dirlen-1] == '/') --dirlen;
+while (dirlen dir[dirlen-1] == '/')
+--dirlen;
if (!dirlen) { /* We had Unixish '/' -- substitute top of current tree */
- if (!decc_posix_compliant_pathnames decc_disable_posix_root) {
-dir = /sys$disk;
-dirlen = 9;
- }
- else
- dirlen = 1;
+if (!decc_posix_compliant_pathnames decc_disable_posix_root) {
+dir = /sys$disk;
+dirlen = 9;
+} else {
+dirlen = 1;
+}
}
if (dirlen (VMS_MAXRSS - 1)) {
- set_errno(ENAMETOOLONG); set_vaxc_errno(RMS$_SYN);
- return NULL;
+set_errno(ENAMETOOLONG);
+set_vaxc_errno(SS$_BUFFEROVF);
+return NULL;
}
trndir = PerlMem_malloc(VMS_MAXRSS + 1);
-if (trndir == NULL) _ckvmssts(SS$_INSFMEM);
+if (trndir == NULL)
+_ckvmssts_noperl(SS$_INSFMEM);
if (!strpbrk(dir+1,/]:)
- (!decc_posix_compliant_pathnames decc_disable_posix_root)) {
- strcpy(trndir,*dir == '/' ? dir + 1: dir);
- trnlnm_iter_count = 0;
- while (!strpbrk(trndir,/]:) my_trnlnm(trndir,trndir,0)) {
-trnlnm_iter_count++;
-if (trnlnm_iter_count = PERL_LNM_MAX_ITER) break;
- }
- dirlen = strlen(trndir);
-}
-else {
- strncpy(trndir,dir,dirlen);
- trndir[dirlen] = '\0';
+(!decc_posix_compliant_pathnames decc_disable_posix_root)) {
+strcpy(trndir,*dir == '/' ? dir + 1: dir);
+trnlnm_iter_count = 0;
+while (!strpbrk(trndir,/]:)
+ simple_trnlnm(trndir, trndir, VMS_MAXRSS)) {
+trnlnm_iter_count++;
+if (trnlnm_iter_count = PERL_LNM_MAX_ITER)
+break;
+}
+dirlen = strlen(trndir);
+} else {
+strncpy(trndir,dir,dirlen);
+trndir[dirlen] = '\0';
}
/* At this point we are done with *dir and use *trndir which is a
@@ -5849,444 +5855,487 @@
* does something useful.
*/
if (dirlen = 2 !strcmp(trndir+dirlen-2,.])) {
- trndir[--dirlen] = '\0';
- trndir[dirlen-1] = ']';
+trndir[--dirlen] = '\0';
+trndir[dirlen-1] = ']';
}
if (dirlen = 2 !strcmp(trndir+dirlen-2,.)) {
- trndir[--dirlen] = '\0';
- trndir[dirlen-1] = '';
+trndir[--dirlen] = '\0';
+trndir[dirlen-1] = '';
}
-if ((cp1 = strrchr(trndir,']')) != NULL || (cp1 = strrchr(trndir,'')) !=
NULL) {
- /* If we've got an explicit filename, we can just shuffle the string. */
- if (*(cp1+1)) hasfilename = 1;
- /* Similarly, we can just back up a level if we've got multiple levels
- of explicit directories in a VMS spec which ends with directories. */
- else {
-for (cp2 = cp1; cp2 trndir; cp2--) {
- if (*cp2 == '.') {
- if ((cp2 - 1 trndir) (*(cp2 - 1) != '^')) {
-/* fix-me, can not scan EFS file specs backward like this */
- *cp2 = *cp1; *cp1 = '\0';
- hasfilename =
[patch@35055] vms.c rmsexpand refactor
This patch makes a version of rmsexpand available for calling with out
an implicit context, which is needed for threaded perl as several
routines do not have or need an implicit context.
This is the sixth of a multi-part conversion to remove access violations
when internal perl warning and error routines, and memory allocation
routines are called with a null pointer for the implicit context.
By removing the implicit context from these routines, it will cause a
compile time error on threaded perl should one of the affected routines
sneak back into this code.
Hopefully this is the last big patch for a while.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /ref7_root/perl/vms/vms.c Sun Dec 7 17:20:31 2008
+++ vms/vms.c Sun Dec 7 17:31:53 2008
@@ -296,6 +296,10 @@
static char *mp_do_tounixspec(pTHX_ const char *, char *, int, int *);
static char *mp_do_pathify_dirspec(pTHX_ const char *dir,char *buf, int ts,
int *);
+static char * int_rmsexpand_vms(
+const char * filespec, char * outbuf, unsigned opts);
+static char * int_rmsexpand_tovms(
+const char * filespec, char * outbuf, unsigned opts);
static char *int_tovmsspec
(const char *path, char *buf, int dir_flag, int * utf8_flag);
static char * int_fileify_dirspec(const char *dir, char *buf, int *utf8_fl);
@@ -5364,384 +5368,478 @@
static char *mp_do_tounixspec(pTHX_ const char *, char *, int, int *);
static char *
-mp_do_rmsexpand
- (pTHX_ const char *filespec,
+int_rmsexpand
+ (const char *filespec,
char *outbuf,
-int ts,
const char *defspec,
unsigned opts,
int * fs_utf8,
int * dfs_utf8)
{
- static char __rmsexpand_retbuf[VMS_MAXRSS];
- char * vmsfspec, *tmpfspec;
- char * esa, *cp, *out = NULL;
- char * tbuf;
- char * esal = NULL;
- char * outbufl;
- struct FAB myfab = cc$rms_fab;
- rms_setup_nam(mynam);
- STRLEN speclen;
- unsigned long int retsts, trimver, trimtype, haslower = 0, isunix = 0;
- int sts;
+char * ret_spec;
+const char * in_spec;
+char * spec_buf;
+const char * def_spec;
+char * vmsfspec, *vmsdefspec;
+char * esa;
+char * esal = NULL;
+char * outbufl;
+struct FAB myfab = cc$rms_fab;
+rms_setup_nam(mynam);
+STRLEN speclen;
+unsigned long int retsts, trimver, trimtype, haslower = 0, isunix = 0;
+int sts;
- /* temp hack until UTF8 is actually implemented */
- if (fs_utf8 != NULL)
-*fs_utf8 = 0;
+/* temp hack until UTF8 is actually implemented */
+if (fs_utf8 != NULL)
+*fs_utf8 = 0;
- if (!filespec || !*filespec) {
-set_vaxc_errno(LIB$_INVARG); set_errno(EINVAL);
-return NULL;
- }
- if (!outbuf) {
-if (ts) out = Newx(outbuf,VMS_MAXRSS,char);
-elseoutbuf = __rmsexpand_retbuf;
- }
+if (!filespec || !*filespec) {
+set_vaxc_errno(LIB$_INVARG); set_errno(EINVAL);
+return NULL;
+}
- vmsfspec = NULL;
- tmpfspec = NULL;
- outbufl = NULL;
-
- isunix = 0;
- if ((opts PERL_RMSEXPAND_M_VMS_IN) == 0) {
-isunix = is_unix_filespec(filespec);
-if (isunix) {
- vmsfspec = PerlMem_malloc(VMS_MAXRSS);
- if (vmsfspec == NULL) _ckvmssts(SS$_INSFMEM);
- if (do_tovmsspec(filespec,vmsfspec,0,fs_utf8) == NULL) {
- PerlMem_free(vmsfspec);
- if (out)
- Safefree(out);
- return NULL;
- }
- filespec = vmsfspec;
+vmsfspec = NULL;
+vmsdefspec = NULL;
+outbufl = NULL;
+
+in_spec = filespec;
+isunix = 0;
+if ((opts PERL_RMSEXPAND_M_VMS_IN) == 0) {
+
+/* If this is a UNIX file spec, convert it to VMS */
+isunix = is_unix_filespec(filespec);
+if (isunix) {
+char * ret_spec;
+vmsfspec = PerlMem_malloc(VMS_MAXRSS);
+if (vmsfspec == NULL)
+_ckvmssts_noperl(SS$_INSFMEM);
- /* Unless we are forcing to VMS format, a UNIX input means
- * UNIX output, and that requires long names to be used
- */
+ret_spec = int_tovmsspec(filespec, vmsfspec, 0, fs_utf8);
+if (ret_spec == NULL) {
+PerlMem_free(vmsfspec);
+return NULL;
+}
+in_spec = (const char *)vmsfspec;
+
+/* Unless we are forcing to VMS format, a UNIX input means
+ * UNIX output, and that requires long names to be used
+ */
#if !defined(__VAX) defined(NAML$C_MAXRSS)
- if ((opts PERL_RMSEXPAND_M_VMS) == 0)
- opts |= PERL_RMSEXPAND_M_LONG;
- else
+if ((opts PERL_RMSEXPAND_M_VMS) == 0)
+opts |= PERL_RMSEXPAND_M_LONG;
+else
#endif
- isunix = 0;
- }
+isunix = 0;
+}
}
- rms_set_fna(myfab, mynam, (char *)filespec, strlen(filespec)); /* cast ok */
- rms_bind_fab_nam(myfab, mynam);
+rms_set_fna(myfab, mynam, (char *)in_spec, strlen(in_spec)); /* cast ok */
+rms_bind_fab_nam(myfab, mynam);
- if (defspec *defspec) {
-int t_isunix;
-t_isunix =
[patch] Lib/File/Path.t (post 5.8.9) catdir used instead of catfile
In the test to see what happens if you try to create a file with the
same name as a directory, catdir is used to create the file
specification instead of catfile.
The operation is expected to fail usually.
However on VMS, directories and files can appear to have the same name,
especially when VMS is reporting filenames in Unix syntax.
So this test should be skipped on VMS.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/lib/File/Path.tThu Dec 4 15:49:40 2008
+++ lib/File/Path.t Sat Dec 6 03:40:52 2008
@@ -341,7 +341,9 @@
# see what happens if a file exists where we want a directory
SKIP: {
-my $entry = catdir($tmp_base, file);
+my $entry = catfile($tmp_base, file);
+skip VMS can have a file and a directory with the same name., 4
+if $Is_VMS;
skip Cannot create $entry, 4 unless open OUT, $entry;
print OUT test file, safe to delete\n, scalar(localtime), \n;
close OUT;
[patch@35050] replace pathify_dirspec in VMS with new version
The mp_do_pathify_dirspec needed enhancements to more accurately parse
VMS file specifications, and also to handle UNIX file specifications the
same way that mp_do_tovmspath() does.
It was simpler to replace than to try to modify the existing routine.
In addition this is the start of fixing issues where routines can be
called with a null thread context, by removing the thread context where
it is not needed.
More patches will be following this.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/vms/vms.c Fri Dec 5 12:13:19 2008
+++ vms/vms.c Sat Dec 6 03:31:43 2008
@@ -362,6 +362,40 @@
int decc_dir_barename = 0;
static int vms_debug_on_exception = 0;
+static int vms_debug_fileify = 0;
+
+
+/* Simple logical name translation */
+static int simple_trnlnm
+ (const char * logname,
+char * value,
+int value_len)
+{
+const $DESCRIPTOR(table_dsc, LNM$FILE_DEV);
+const unsigned long attr = LNM$M_CASE_BLIND;
+struct dsc$descriptor_s name_dsc;
+int status;
+unsigned short result;
+struct itmlst_3 itlst[2] = {{value_len, LNM$_STRING, value, result},
+{0, 0, 0, 0}};
+
+name_dsc.dsc$w_length = strlen(logname);
+name_dsc.dsc$a_pointer = (char *)logname;
+name_dsc.dsc$b_dtype = DSC$K_DTYPE_T;
+name_dsc.dsc$b_class = DSC$K_CLASS_S;
+
+status = sys$trnlnm(attr, table_dsc, name_dsc, 0, itlst);
+
+if ($VMS_STATUS_SUCCESS(status)) {
+
+/* Null terminate and return the string */
+ /*--*/
+ value[result] = 0;
+return result;
+}
+
+return 0;
+}
/* Is this a UNIX file specification?
* No longer a simple check with EFS file specs
@@ -888,6 +922,27 @@
}
+/* Routine to determine if the file specification ends with .dir */
+static int is_dir_ext(char * e_spec, int e_len, char * vs_spec, int vs_len) {
+
+/* e_len must be 4, and version must be = 2 characters */
+if (e_len != 4 || vs_len 2)
+return 0;
+
+/* If a version number is present, it needs to be one */
+if ((vs_len == 2) (vs_spec[1] != '1'))
+return 0;
+
+/* Look for the DIR on the extension */
+if ((toupper(e_spec[1]) == 'D')
+(toupper(e_spec[2]) == 'I')
+(toupper(e_spec[3]) == 'R')) {
+return 1;
+}
+return 0;
+}
+
+
/* my_maxidx
* Routine to retrieve the maximum equivalence index for an input
* logical name. Some calls to this routine have no knowledge if
@@ -6236,280 +6291,434 @@
char *Perl_fileify_dirspec_utf8_ts(pTHX_ const char *dir, char *buf, int *
utf8_fl)
{ return do_fileify_dirspec(dir,buf,1,utf8_fl); }
-/*{{{ char *pathify_dirspec[_ts](char *path, char *buf)*/
-static char *mp_do_pathify_dirspec(pTHX_ const char *dir,char *buf, int ts,
int * utf8_fl)
-{
-static char __pathify_retbuf[VMS_MAXRSS];
-unsigned long int retlen;
-char *retpath, *cp1, *cp2, *trndir;
+static char * int_pathify_dirspec_simple(const char * dir, char * buf,
+char * v_spec, int v_len, char * r_spec, int r_len,
+char * d_spec, int d_len, char * n_spec, int n_len,
+char * e_spec, int e_len, char * vs_spec, int vs_len) {
+
+/* VMS specification - Try to do this the simple way */
+if ((v_len + r_len + d_len) 0) {
+int is_dir;
+
+/* No name or extension component, already a directory */
+if ((n_len + e_len + vs_len) == 0) {
+strcpy(buf, dir);
+return buf;
+}
+
+/* Special case, we may get [.foo]bar instead of [.foo]bar.dir */
+/* This results from catfile() being used instead of catdir() */
+/* So even though it should not work, we need to allow it */
+
+/* If this is .DIR;1 then do a simple conversion */
+is_dir = is_dir_ext(e_spec, e_len, vs_spec, vs_len);
+if (is_dir || (e_len == 0)) {
+ int len;
+ len = v_len + r_len + d_len - 1;
+ char dclose = d_spec[d_len - 1];
+ strncpy(buf, dir, len);
+ buf[len] = '.';
+ len++;
+ strncpy(buf[len], n_spec, n_len);
+ len += n_len;
+ buf[len] = dclose;
+ buf[len + 1] = '\0';
+ return buf;
+}
+
+#ifdef HAS_SYMLINK
+else {
+/* In the olden days, a directory needed to have a .DIR */
+/* extension to be a valid directory, but now it could */
+/* be a symbolic link */
+int len;
+len = v_len + r_len + d_len - 1;
+char dclose = d_spec[d_len - 1];
+strncpy(buf, dir, len);
+buf[len] = '.';
+len++;
+strncpy(buf[len], n_spec, n_len);
+len += n_len;
+if (e_len 0) {
+if (decc_efs_charset) {
+buf[len] = '^';
+len++;
+strncpy(buf[len], e_spec, e_len);
+len += e_len;
+
[patch@34995] vms.c - Memory freed from wrong pool
In trim_unixpath, the wrong free routine was being used resulting in
data corruption.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/vms/vms.c Sun Nov 23 22:54:17 2008
+++ vms/vms.c Wed Dec 3 19:05:18 2008
@@ -9345,10 +9345,10 @@
char def[NAM$C_MAXRSS+1], *st;
if (getcwd(def, sizeof def,0) == NULL) {
- Safefree(unixified);
- Safefree(unixwild);
- Safefree(lcres);
- Safefree(tpl);
+ PerlMem_free(unixified);
+ PerlMem_free(unixwild);
+ PerlMem_free(lcres);
+ PerlMem_free(tpl);
return 0;
}
if (!decc_efs_case_preserve) {
Re: [patch@34955] Achive::Tar fix for VMS.
Craig A. Berry wrote: On Nov 30, 2008, at 6:04 PM, John E. Malmberg wrote: Test 04_Resolved_Issues was failing on VMS because it was translating .. to __. Use vmspath() instead so that dots are escaped if needed. Also filed as: http://rt.cpan.org/Public/Bug/Display.html?id=41329 Are you sure it isn't already resolved by this one: http://rt.cpan.org/Public/Bug/Display.html?id=39933 I did not see that one. I did not check the resolved queue on rt.cpan.org when I looked it up. I think that using vmspath() is more robust as it will correctly any translations that need to be done for converting Unix character sets to ODS-2 when needed, and pass them through when they do not need conversions. This way in ODS-5 mode a directory will not be unexpectedly renamed. -John [EMAIL PROTECTED] Personal Opinion Only
[patch@34950]configure.com fix usedevel
configure.com needs a little more work to implement usedevel. -John [EMAIL PROTECTED] Personal Opinion Only --- /rsync_root/perl/configure.com Fri Nov 28 01:53:05 2008 +++ configure.com Fri Nov 28 11:12:21 2008 @@ -6520,6 +6520,7 @@ $ WC usedebugging_perl='+use_debugging_perl+' $ WC usedefaulttypes=' + usedefaulttypes + '! VMS-specific $ WC usecrosscompile='undef' +$ WC usedevel=' + usedevel + ' $ WC usedl=' + usedl + ' $ WC usedtrace='undef' $ WC usefaststdio=' + usefaststdio + '
Re: [patch@34950]configure.com fix usedevel
Craig A. Berry wrote: On Nov 28, 2008, at 11:31 AM, John E. Malmberg wrote: configure.com needs a little more work to implement usedevel. -John [EMAIL PROTECTED] Personal Opinion Only --- /rsync_root/perl/configure.comFri Nov 28 01:53:05 2008 +++ configure.comFri Nov 28 11:12:21 2008 @@ -6520,6 +6520,7 @@ $ WC usedebugging_perl='+use_debugging_perl+' $ WC usedefaulttypes=' + usedefaulttypes + '! VMS-specific $ WC usecrosscompile='undef' +$ WC usedevel=' + usedevel + ' It doesn't look to me like Configure writes usedevel to config.sh either, so I'm not sure why configure.com would need to. Is there a particular problem you are trying to solve? Change 34950 broke building perl on VMS with out this additional fix. I have not tried building on other platforms. -John
Re: [patch@34896] File::Compare test fixes for VMS.
Craig A. Berry wrote: On Nov 24, 2008, at 8:32 PM, John E. Malmberg wrote: In lib/File/Compare.t : The tests with the filename having a trailing space was not working correctly on VMS in the traditional mode, and was leaving one of the temporary files behind. With VMS in the Extended File System (EFS) character set mode, the test fails because it requires two things: 1. VMS to be in UNIX file sharing modes. This is default exclusive locking disabled. 2. flush() on file handles need to be implemented/fixed on VMS to work. It also needs to have the temp directory as chosen by File::Temp to be set to an ODS-5 volume. -John [EMAIL PROTECTED] Personal Opinion Only --- /rsync_root/perl/lib/File/Compare.tTue Jun 13 14:29:14 2006 +++ lib/File/Compare.tMon Nov 24 19:24:36 2008 I appreciate the effort but something is not adding up here. We start with a test file that has no VMS-specific workarounds at all. It uses File::Spec and File::Temp and generally behaves itself from a portability standpoint. It only appears to behave in the VMS environment, it is not actually doing the intended test, and as a side effect it is leaving behind the temp file. Then, in order to run it in a VMS environment that emulates unixy behavior we have to add 60+ lines of VMS-specific code to the test. Huh? Something's wrong with this picture. I can see the failures and I agree something needs to be done, though I haven't looked at it in detail to think about what that might be. But I sure hope it's something less intrusive than this. The additional lines are to provide diagnostics to the VMS user, because when EFS charset mode is enabled, the test tries to open the file a second time. That open fails unless DECC$FILE_SHARING is enabled. Then the test will still fail because VMS requires the output to be flushed after the write a filehandle for the data to actually be in the file. Previous investigations showed that while the flush() method is available on filehandles, on VMS, it currently does not actually flush the buffer. -John [EMAIL PROTECTED] Personal Opinion Only
Re: how to link compiler logical from mmk
purnima bhandari wrote: Hi All, Thanks for all the help... I am able to link by adding my own .com fine which is defining the compiler's needed logical.I added that one in the descrip.mms file into the .FIRST location for MMK and i also modified the descrip_mms.template for Perl5.10.0. And as I stated in my first e-mail, making such changes would not result in perl building successfully. The line that you added attempts to change the version of the C compiler used in the compile. This has no effect on what run time library is in use. Why do you think you need to do this? Nothing in your previous posts indicate that this is needed to do what you have stated you are trying to do. Perl 5.10.0 should compile fine with any version of DEC/Compaq/HP C on any VMS platform later than 5.5-2. There are a few small patches needed for some older versions that have been posted to this list. Now the build is going fine except for the file VMS.C.Below is the warning i am getting. CC/DECC/NOANSI_ALIAS /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList- /float=ieee/ieee=denorm/Define=(PERL_CORE,_USE_STD_STAT=1) VMS.C VMS_INO_T_COPY(statbufp-st_ino, statbufp-crtl_stat.st_ino); ^ %CC-W-CVTDIFTYPES, In this statement, statbufp-crtl_stat.st_ino of type pointer to unsigned short, is being converted to unsig ned int. You have set a macro definition that is not available in the C RTL header file for the version of VMS you are building on. This has nothing to do with the compiler version you are using. Changing the compiler version is done for several reasons, but not the one that you gave in your previous e-mail, which is why changing it does not solve your problem. The compiler version used is DEC C V 7.x. Tell us what you are trying to accomplish and why. Changing the version that the compiler you are using will not help with run-time library issues. On 17 Nov 2008, at 03:38 , purnima bhandari wrote: I am trying to build a perl5.10.0 using MMK. I am linking against the 8.3 decc$shr on a 7.3-2 system. This has nothing to do with the compiler version. Compiler virsion of the 7.3-2 is below. $ cc/ver DEC C V5.7-006 on OpenVMS Alpha V7.3-2 $ Here are the issues you are facing: 1. PERL uses DCL to determine what features are available on the system perl is being built on in the configure state. This means that even if you change the link to use the newer DECC$SHR, and got everything else to work, you will still end up with a Perl that is limited to what is available on the build system. In some cases it does this by building small programs, in others by internal knowledge. The compiler version has nothing at all to do with this. Because you got incompatible parameters in your resulting build, it looks like you did something to bypass that phase of the Perl build. 2. In the Perl build procedure, perl builds several helper programs that are run. If you succeed in linking them against the newer DECC$SHR, they may not run, and may fail in odd ways. The compiler version has nothing at all to do with this. 3. The compiler by default, like DCL will use the header file libraries for the build platform. This will result in it only using the features that are available on the build platform, even if you get it to link with the newer library. I am very new to the VMS .Can anyone please help me with their suggestions? What are you trying to do? There is a need for more people to be hacking on VMS perl internals, so I do not want to chase you away. However if you are new, you should start with simple things, and explain why you think you need to do complex solutions. VMS does not make it as hard to do things as other platforms, so trying to solve simple problems by doing complex things as maintaining different compiler versions is usually a waste of time. -John [EMAIL PROTECTED] Personal Opinion Only
[patch@34896] File::Compare test fixes for VMS.
In lib/File/Compare.t :
The tests with the filename having a trailing space was not working
correctly on VMS in the traditional mode, and was leaving one of the
temporary files behind.
With VMS in the Extended File System (EFS) character set mode, the test
fails because it requires two things:
1. VMS to be in UNIX file sharing modes.
This is default exclusive locking disabled.
2. flush() on file handles need to be implemented/fixed on VMS to work.
It also needs to have the temp directory as chosen by File::Temp to be
set to an ODS-5 volume.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/lib/File/Compare.t Tue Jun 13 14:29:14 2006
+++ lib/File/Compare.t Mon Nov 24 19:24:36 2008
@@ -14,6 +14,28 @@
}
}
+my $vms_unix_rpt = 0;
+my $vms_efs = 0;
+my $vms_file_sharing = 0;
+my $vms_default_mode = 0;
+
+if ($^O eq 'VMS') {
+$vms_default_mode = 1;
+if (eval 'require VMS::Feature') {
+$vms_unix_rpt = VMS::Feature::current('filename_unix_report');
+$vms_efs = VMS::Feature::current('efs_charset');
+$vms_file_sharing = VMS::Feature::current('file_sharing');
+} else {
+my $unix_rpt = $ENV{'DECC$FILENAME_UNIX_REPORT'} || '';
+my $efs_charset = $ENV{'DECC$EFS_CHARSET'} || '';
+my $file_sharing = $ENV{'DECC$FILE_SHARING'} || '';
+$vms_unix_rpt = $unix_rpt =~ /^[ET1]/i;
+$vms_efs = $efs_charset =~ /^[ET1]/i;
+$vms_file_sharing = $file_sharing =~ /^[ET1]/i;
+}
+$vms_default_mode = 0 if ($vms_efs $vms_file_sharing);
+}
+
print 1..13\n;
use File::Compare qw(compare compare_text);
@@ -78,7 +100,16 @@
my $template = File::Spec-catfile(File::Spec-tmpdir, 'fcmp');
my($tfh,$filename) = mkstemp($template);
+
# NB. The trailing space is intentional (see [perl #37716])
+
+ # With the default VMS mode, the trailing space is stripped off
+ # silently. Which means we open a second version of the same filename.
+ # Which makes the code below appear to work until the extended character
+ # set becomes available. Then the two filenames are different, and
+ # this test attempts to open a file already open by the temp file handle.
+ # by default VMS does not allow this unless DECC$FILE_SHARING is set.
+
open my $tfhSP, , $filename
or die Could not open '$filename ' for writing: $!;
binmode($tfhSP);
@@ -93,25 +124,62 @@
print $tfhSP $data;
close($tfhSP);
}
+
+ # X/Open requires this if you expect the data to actually be readable
+ # by other streams, but this only affects VMS.
+ if ($vms_file_sharing) {
+ $tfh-flush or die Could not flush filehandle: $!;
+ }
+
seek($tfh,0,0);
$donetests[0] = compare($tfh, 'README');
$donetests[1] = compare($filename, 'README');
- unlink0($tfh,$filename);
+
+ # In VMS default mode, this unlink fails because it sees $filename.' '
+ # instead of $filename and it is not the file handled that is open.
+ # So we can not do this until after $filename.'' is unlinked.
+ unlink0($tfh,$filename) unless $vms_default_mode;
+
$donetests[2] = compare('README', $filename );
unlink $filename ;
+
+ # In VMS default mode, clean this up now.
+ unlink0($tfh,$filename) if $vms_default_mode;
};
print # problem '$@' when testing with a temporary file\n if $@;
if (@donetests == 3) {
print not unless $donetests[0] == 0;
- print ok 11 # fh/file [$donetests[0]]\n;
- print not unless $donetests[1] == 0;
- print ok 12 # file/file [$donetests[1]]\n;
+ print ok 11 # fh/file [$donetests[0]] \n;
+ unless ($donetests[1] == 0) {
+ if ($vms_file_sharing) {
+ $vms_todo_flush = TODO - flush() not implmented on VMS; ;
+ } else {
+ print # DECC\$FILE_SHARING needs to be enabled for test 12\n;
+ }
+ print not ;
+ }
+ print ok 12 # $vms_todo_flush file/file [$donetests[1]]\n;
print not unless $donetests[2] == 0;
print ok 13 # ;
print TODO if $^O eq cygwin; # spaces after filename silently trunc'd
print file/fileCR [$donetests[2]]\n;
}
else {
+ if ($^O eq 'VMS') {
+ if ($vms_efs) {
+ print # DECC\$EFS_CHARSET mode enabled.\n;
+ if (!$vms_file_sharing) {
+ print not ok 11 #Skip\nok 12 # Skip\nok 13 # Skip\n;
+ print # DECC\$FILE_SHARING needs to be enabled for this
test.\n;
+ }
+ print # Temporary directory may not be on an ODS-5 volume\n;
+
+ } else {
+ print not ok 11\nok 12 # Skip\nok 13 # Skip\n;
+ print # Could not create test file in temp directory.\n;
+ }
+ } else {
print ok 11# Skip\nok 12 # Skip\nok 13 # Skip Likely due to File::Temp\n;
+ }
}
[patch@34896] vms readdir() fixes for UNIX/EFS mode
Readdir() on VMS, when opening a directory with a UNIX file
specification, should return all the files in UNIX format.
This includes dropping the .DIR from the directory specifications.
Because traditionally Perl has not done this, this fix will only be done
when the DECC$EFS_CHARSET feature is enabled.
Next on the fix list for Unix compatibility mode, * is always
returning specifications in VMS format instead of UNIX format when
DECC$FILENAME_UNIX_REPORT is active.
Regards,
-John
--- /rsync_root/perl/vms/vms.c Mon Nov 10 06:51:29 2008
+++ vms/vms.c Sat Nov 22 10:46:34 2008
@@ -9631,11 +9631,32 @@
vs_spec,
vs_len);
-/* Drop NULL extensions on UNIX file specification */
-if ((dd-flags PERL_VMSDIR_M_UNIXSPECS
- (e_len == 1) decc_readdir_dropdotnotype)) {
- e_len = 0;
- e_spec[0] = '\0';
+if (dd-flags PERL_VMSDIR_M_UNIXSPECS) {
+
+/* In Unix report mode, remove the .dir;1 from the name */
+/* if it is a real directory. */
+if (decc_filename_unix_report || decc_efs_charset) {
+if ((e_len == 4) (vs_len == 2) (vs_spec[1] == '1')) {
+if ((toupper(e_spec[1]) == 'D')
+(toupper(e_spec[2]) == 'I')
+(toupper(e_spec[3]) == 'R')) {
+Stat_t statbuf;
+int ret_sts;
+
+ret_sts = stat(buff, (stat_t *)statbuf);
+if ((ret_sts == 0) S_ISDIR(statbuf.st_mode)) {
+e_len = 0;
+e_spec[0] = 0;
+}
+}
+}
+}
+
+/* Drop NULL extensions on UNIX file specification */
+ if ((e_len == 1) decc_readdir_dropdotnotype) {
+ e_len = 0;
+ e_spec[0] = '\0';
+}
}
strncpy(dd-entry.d_name, n_spec, n_len + e_len);
Re: MM_VMS and File::Spec::VMS.pm intertanglement.
Craig A. Berry wrote: On Wed, Nov 12, 2008 at 10:13 PM, Michael G Schwern [EMAIL PROTECTED] wrote: John E. Malmberg wrote: Putting a print STDERR statement shows that is not the case, that the methods of those names contained in File::Spec::VMS are used unless they are called by MM_VMS. The internal calls to eliminate_macros() and fixpath() should simply be removed from File::Spec::VMS. They're only used to deal with make macros, its a very MakeMaker specific thing. They were left in place so that new versions of File::Spec would continue to work with older (pre 6.11 which is from perl 5.8.0 and older) versions of MakeMaker. That was five and a half years ago. It's safe to remove them. Whether it's safe or not it's certainly worth a try. There are a *lot* more tests now for MM, File::Spec, and all the core modules that use File::Spec than there were five and half years ago, so if removing these breaks something I think we'd know pretty quickly. I am not planning on removing those routines for the default mode of VMS, but will not be using them when the DECC$EFS_CHARSET mode is enabled. In addition to eliminating macros, they can change the file specification, and existing scripts ported to VMS may expect this file spec change. My goal with the EFS_CHARSET and REPORT_UNIX modes is to be able to run generic Perl scripts with out having to modify them specifically for VMS, as that is what I am encountering on open source build procedures. Now about MM_VMS, based on previous e-mail discussions, these routines exist because VMS PERL by default does not map the %ENV hash to DCL shell symbols. If those specific $ENV values put in the makefile where exported using the DCLsym module in the format MMK/MMS could use, then MM_VMS would not need to be eliminating the macros. Now with the macros elimninated on VMS, the resulting makefile can be run outside of the script that generated it, and it will still work. But if it were changed to have the environment variables set by perl, then the resulting makefile would probably only be runnable by the script that generated it, because that is also what set the environment variables. But that should also be the case with UNIX. Or am I missing something here? Also, MMK/MMS should be able to use UNIX filename syntax, as long as every file reference is in UNIX format. That should be able to simplify the work in getting mm_vms to support the extended character set mode. -John [EMAIL PROTECTED] Personal Opinion Only
MM_VMS and File::Spec::VMS.pm intertanglement.
The comments for eliminate_macros() and fixpath() in File::Spec::VMS imply that they are only used in older versions of Make Maker that does not contain them. Putting a print STDERR statement shows that is not the case, that the methods of those names contained in File::Spec::VMS are used unless they are called by MM_VMS. I am now trying to update File::Spec to handle VMS EFS character specifications and GNV (GNU is not VMS) Unix compatibilty mode, so I will need to first update File::Spec::VMS, and then MM_VMS later. In the EFS (Extended character set) mode, in addition to handling the extended character set, the routines will return Unix syntax for Unix input and VMS syntax for VMS input. For cases where there is no input, or the input does not indicate the output format, then the output will be in VMS syntax unless the UNIX compatibilty mode is also on. If that mode is on, then ambigous output will be in Unix syntax. This appears to match the expectation of most of the Perl scripts that I have worked on getting ported to VMS. -John [EMAIL PROTECTED] Personal Opinion Only
Re: MM_VMS and File::Spec::VMS.pm intertanglement.
Michael G Schwern wrote: John E. Malmberg wrote: The comments for eliminate_macros() and fixpath() in File::Spec::VMS imply that they are only used in older versions of Make Maker that does not contain them. Putting a print STDERR statement shows that is not the case, that the methods of those names contained in File::Spec::VMS are used unless they are called by MM_VMS. I am now trying to update File::Spec to handle VMS EFS character specifications and GNV (GNU is not VMS) Unix compatibilty mode, so I will need to first update File::Spec::VMS, and then MM_VMS later. In the EFS (Extended character set) mode, in addition to handling the extended character set, the routines will return Unix syntax for Unix input and VMS syntax for VMS input. For cases where there is no input, or the input does not indicate the output format, then the output will be in VMS syntax unless the UNIX compatibilty mode is also on. If that mode is on, then ambigous output will be in Unix syntax. This appears to match the expectation of most of the Perl scripts that I have worked on getting ported to VMS. Do you need anything, or was that just an FYI/RFC? Mostly a FYI/RFC. Would there be an issue if File::Spec::VMS get the changes before MM_VMS? The last time I did this with Perl 5.8.6/7, I just made the changes to get the tests to pass. This time I am trying to get the operations to be as correct as possible. So I need to re-write File::Spec::VMS so that in EFS mode it almost never calls vmsify or unixify, and I do not know how long that will take. -John [EMAIL PROTECTED] Personal Opinion Only
Re: patch@34561 VMS exec handling / cwd realpath fixes
Craig A. Berry wrote: On Thu, Oct 30, 2008 at 11:03 AM, Craig A. Berry [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2008 at 10:21 PM, John E. Malmberg [EMAIL PROTECTED] wrote: Resubmitting for review. I removed the setup_cmddsc, and the unneeded readdir stuff, so this patch is what is needed for getting the symbolic links to be encoded and decoded properly in VMS.C and for CWD in pathtools. I've applied the changes to Perl_my_symlink as #34667. That patch was badly mangled. It looked like a diff of a diff rather than a diff of code and it also messed up the curly braces. Hopefully fixed in 34668. That'll teach me to apply things I think I've already tested. Sorry about that, I missed cleaning up that file before preparing the individual diffs. -John Personal Opinion Only
[patch@34600] vms.c setup_cmddsc
This is part of the patch previously submitted as part of a multi-part
patch.
This removes a trailing . that results in ODS-5 mode when converting a
Unix foo/bar specification to be [.foo]bar..
This is incompatible with having setup_cmddsc searching for the
resulting binary by appending .exe or . to the specification.
This allows the [.vms]test.com program to be run in the GNV/Unix
compatible mode in order to start validating Perl for it.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/vms/vms.c Wed Oct 22 19:26:20 2008
+++ vms/vms.c Wed Oct 29 21:52:12 2008
@@ -9892,6 +9892,19 @@
*cp2 = '\0';
if (do_tovmsspec(resspec,cp,0,NULL)) {
s = vmsspec;
+
+ /* When a UNIX spec with no file type is translated to VMS, */
+ /* A trailing '.' is appended under ODS-5 rules.*/
+ /* Here we do not want that trailing . as it prevents */
+ /* Looking for a implied .exe type. */
+ if (decc_efs_charset) {
+ int i;
+ i = strlen(vmsspec);
+ if (vmsspec[i-1] == '.') {
+ vmsspec[i-1] = '\0';
+ }
+ }
+
if (*rest) {
for (cp2 = vmsspec + strlen(vmsspec);
*rest cp2 - vmsspec sizeof vmsspec;
Re: patch@34561 VMS exec handling / cwd realpath fixes
Ok,
Resubmitting for review.
I removed the setup_cmddsc, and the unneeded readdir stuff, so this
patch is what is needed for getting the symbolic links to be encoded and
decoded properly in VMS.C and for CWD in pathtools.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- /rsync_root/perl/lib/cwd.pm Sun Oct 19 05:26:56 2008
+++ lib/cwd.pm Wed Oct 22 23:56:34 2008
@@ -647,23 +647,15 @@
return $ENV{'DEFAULT'} unless @_;
my $path = shift;
-if (-l $path) {
-my $link_target = readlink($path);
-die Can't resolve link $path: $! unless defined $link_target;
-
-return _vms_abs_path($link_target);
-}
-
-if (defined VMS::Filespec::vms_realpath) {
-my $path = $_[0];
+if (defined VMS::Filespec::vmsrealpath) {
if ($path =~ m#(?=\^)/# ) {
# Unix format
-return VMS::Filespec::vms_realpath($path);
+return VMS::Filespec::unixrealpath($path);
}
# VMS format
- my $new_path = VMS::Filespec::vms_realname($path);
+ my $new_path = VMS::Filespec::vmsrealpath($path);
# Perl expects directories to be in directory format
$new_path = VMS::Filespec::pathify($new_path) if -d $path;
@@ -673,6 +665,13 @@
# Fallback to older algorithm if correct ones are not
# available.
+if (-l $path) {
+my $link_target = readlink($path);
+die Can't resolve link $path: $! unless defined $link_target;
+
+return _vms_abs_path($link_target);
+}
+
# may need to turn foo.dir into [.foo]
my $pathified = VMS::Filespec::pathify($path);
$path = $pathified if defined $pathified;
--- /rsync_root/perl/ext/cwd/t/cwd.tTue Jan 22 22:17:18 2008
+++ ext/cwd/t/cwd.t Wed Oct 22 23:32:36 2008
@@ -173,6 +173,15 @@
$ENV{PERL_CORE} ? $Test_Dir :
File::Spec-catdir('t', $Test_Dir)
)
);
+if ($^O eq 'VMS') {
+ # Not easy to predict the physical volume name
+ $want = $ENV{PERL_CORE} ? $Test_Dir : File::Spec-catdir('t',
$Test_Dir);
+
+ # So just use the relative volume name
+ $want =~ s/^\[//;
+
+ $want = quotemeta($want);
+}
like($abs_path, qr|$want$|i);
like($fast_abs_path, qr|$want$|i);
--- /rsync_root/perl/vms/vms.c Wed Oct 22 19:26:20 2008
+++ vms/vms.c Wed Oct 29 22:04:08 2008
@@ -12990,14 +12990,41 @@
/*
* A thin wrapper around decc$symlink to make sure we follow the
* standard and do not create a symlink with a zero-length name.
+ *
+ * Also in ODS-2 mode, existing tests assume that the link target
+ * will be converted to UNIX format.
*/
-/*{{{ int my_symlink(const char *path1, const char *path2)*/
-int my_symlink(const char *path1, const char *path2) {
- if (!path2 || !*path2) {
+/*{{{ int my_symlink(pTHX_ const char *contents, const char *link_name)*/
+int Perl_my_symlink(pTHX_ const char *contents, const char *link_name) {
+ if (!link_name || !*link_name) {
SETERRNO(ENOENT, SS$_NOSUCHFILE);
return -1;
}
- return symlink(path1, path2);
+
+ if (decc_efs_charset) {
+ return symlink(contents, link_name);
+ } else {
+ int sts;
+ char * utarget;
+
+ /* Unless we are in ODS-5 mode, convert the symlink target to UNIX */
+ /* because in order to work, the symlink target must be in UNIX format */
+
+ /* As symbolic links can hold things other than files, we will only do */
+ /* the conversion in in ODS-2 mode */
+
+ Newx(utarget, VMS_MAXRSS + 1, char);
+ if (do_tounixspec(contents, utarget, 0, NULL) == NULL) {
+
+ /* This should not fail, as an untranslatable filename */
+ /* should be passed through */
+ utarget = (char *)contents;
+ }
+ sts = symlink(utarget, link_name);
+ Safefree(utarget);
+ return sts;
+ }
+
}
/*}}}*/
@@ -13203,7 +13230,100 @@
if (haslower) __mystrtolower(rslt);
}
}
- }
++ } else {
++
++ /* Now for some hacks to deal with backwards and forward */
++ /* compatibilty */
++ if (!decc_efs_charset) {
++
++ /* 1. ODS-2 mode wants to do a syntax only translation */
++ rslt = do_rmsexpand(filespec, outbuf,
++ 0, NULL, 0, NULL, utf8_fl);
++
++ } else {
++ if (decc_filename_unix_report) {
++ char * dir_name;
++ char * vms_dir_name;
++ char * file_name;
++
++ /* 2. ODS-5 / UNIX report mode should return a failure */
++ /*if the parent directory also does not exist */
++ /*Otherwise, get the real path for the parent */
++ /*and add the child to it.
++
++ /* basename / dirname only available for VMS 7.0+ */
++
