[perl #36733] %SIG not properly local-ized
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #36733] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36733 This is a bug report for perl from [EMAIL PROTECTED], generated with the help of perlbug 1.35 running under perl v5.8.6. - The construct local %SIG = %SIG; does *not* make an exact local copy of %SIG, as it should. The program perl -e 'print scalar keys %SIG,\n; local %SIG = %SIG; print scalar keys %SIG, \n' prints 49 0 instead of (something like) 49 49 as it should. For comparison, another magic hash, %ENV, does not have the same problem. perl -e 'print scalar keys %ENV,\n; local %ENV = %ENV; print scalar keys %ENV, \n' 61 61 - --- Flags: category=core severity=medium --- Site configuration information for perl v5.8.6: Configured by mb29450 at Wed Dec 8 21:44:47 PST 2004. Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=solaris, osvers=2.9, archname=sun4-solaris uname='sunos suttles 5.9 generic_112233-05 sun4u sparc sunw,sun-blade-1000 ' config_args='-ds -e -Dprefix=/usr/local' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-I/usr/local/include' ccversion='Sun C 5.5 Patch 112760-04 2003/10/03', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 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='cc', ldflags =' -L/usr/lib -L/usr/ccs/lib -L/u/SUNWspro/prod/lib -L/usr/local/lib ' libpth=/usr/lib /usr/ccs/lib /u/SUNWspro/prod/lib /usr/local/lib libs=-lsocket -lnsl -ldl -lm -lc perllibs=-lsocket -lnsl -ldl -lm -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-KPIC', lddlflags='-G -L/usr/lib -L/usr/ccs/lib -L/u/SUNWspro/prod/lib -L/usr/local/lib' Locally applied patches: --- @INC for perl v5.8.6: /usr/local/lib/perl5/5.8.6/sun4-solaris /usr/local/lib/perl5/5.8.6 /usr/local/lib/perl5/site_perl/5.8.6/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.6 /usr/local/lib/perl5/site_perl/5.8.5/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.5 /usr/local/lib/perl5/site_perl/5.8.4/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.4 /usr/local/lib/perl5/site_perl/5.8.3/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.3 /usr/local/lib/perl5/site_perl/5.8.1/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.1 /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl . --- Environment for perl v5.8.6: HOME=/u/martin LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/u/martin/bin:/u/martin/bin/sun:/usr/java1.5.0/bin:/opt/Acrobat5/bin:/usr/local/bin:/usr/local/samba/bin:/usr/local/apache2/bin:/usr/sfw/bin:/opt/sfw/bin:/usr/dt/bin:/usr/openwin/bin:/usr/xpg4/bin:/usr/proc/bin:/usr/ccs/bin:/usr/bin:/sbin:/usr/sbin:/devtools/sparc/SUNWspro/SS10/bin PERL_BADLANG (unset) SHELL=/usr/bin/zsh
Re: [patch] [EMAIL PROTECTED] - t/op/pack.t undefined value fix
John E. Malmberg wrote:
This test is exiting before running any tests with an undefined value
being referenced if $Config{u64size} is not defined.
Thanks, applied as change #25249.
Re: [EMAIL PROTECTED] - ext/Compress/Zlib on VMS.
John E. Malmberg wrote:
The script 03examples.t is failing at test 1 because the includes seem
to be set wrong for VMS.
--- ext/compress/zlib/t/03examples_t.blead Sun Jul 31 22:54:06 2005
+++ ext/compress/zlib/t/03examples.tSun Jul 31 22:54:12 2005
@@ -42,7 +42,7 @@
my $Inc = '' ;
if ($^O eq 'VMS') {
- $Inc = '-I[.blib.lib] -I[.blib.arch]';
+ $Inc = '-I[-.lib] -I[-.arch]';
}
elsif ($^O eq 'MSWin32') {
foreach (@INC)
This gets the script passing up to test 10 which causes the subsequent
tests to fail.
Thanks, patch applied as #25250. (cc:'ing Paul Marquess)
Re: [EMAIL PROTECTED] on OpenVMS (not good)
John E. Malmberg wrote: This requires fixing in multiple places. perl.h, util.c, and embed.fnc, and this seems to require a running perl to rebuild proto.h Thanks, applied as change #25251.
Re: [perl #36622] y/// at end of file
Michael G Schwern wrote: Bleadperl appears to have this fixed. A test is attached. Ironically the fresh_perl test function would always append a newline to the code being tested. I've whacked that out, it was a hold over from the original code in t/run/kill_perl.t. Thanks, applied as change #25252.
Re: [PATCH] POD typos
Piotr Fusik wrote: I've extracted a list of words from all the PODs and spell-checked it. The result is in the attachment. Thanks, applied, except bits that touch dual-live modules. I didn't apply the bit to perltoc.pod, which is a generated document, and I backported the bit to perlapi.pod to its original source file XSUB.h.
[PATCH] Configure : linux amd64
This patch adds 2 cpp symbols to be checked by Configure for linux/gcc on AMD64. --- Configure (révision 5520) +++ Configure (copie de travail) @@ -19995,7 +19995,7 @@ $cat 'EOSH' Cppsym.know a29k ABI64 aegis AES_SOURCE AIX AIX32 AIX370 AIX41 AIX42 AIX43 AIX_SOURCE aixpc ALL_SOURCE -alliant alpha am29000 AM29000 AMD64 amiga AMIGAOS AMIX +alliant alpha am29000 AM29000 AMD64 amd64 amiga AMIGAOS AMIX ansi ANSI_C_SOURCE apollo ardent ARM32 atarist att386 att3b BeOS BIG_ENDIAN BIT_MSF bsd BSD bsd43 bsd4_2 bsd4_3 BSD4_3 bsd4_4 BSD_4_3 BSD_4_4 BSD_NET2 BSD_TIME BSD_TYPES BSDCOMPAT bsdi @@ -20053,7 +20053,7 @@ USE_MISC USE_POSIX USE_POSIX199309 USE_POSIX199506 USE_POSIX2 USE_REENTRANT USE_SVID USE_UNIX98 USE_XOPEN USE_XOPEN_EXTENDED USGr4 USGr4_2 -Utek UTek UTS UWIN uxpm uxps vax venix VMESA vms xenix Xenix286 +Utek UTek UTS UWIN uxpm uxps vax venix VMESA vms x86_64 xenix Xenix286 XOPEN_SOURCE XOPEN_SOURCE_EXTENDED XPG2 XPG2_EXTENDED XPG3 XPG3_EXTENDED XPG4 XPG4_EXTENDED z8000
Re: Smoke [5.9.3] 25245 FAIL(F) MSWin32 Win2000 SP4 (x86/1 cpu)
Abe Timmerman wrote: Op een mooie zomerdag (Friday 29 July 2005 21:11),schreef Abe Timmerman: Automated smoke report for 5.9.3 patch 25245 neewa: x86 Family 6 Model 5 Stepping 2(~450 MHz) (x86/1 cpu) onMSWin32 - Win2000 SP4 using bcc32 version 5.5.1 smoketime 2 hours 13 minutes (average 1 hour 6 minutes) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25245 Configuration (common) -DCCHOME=C:\Borland\BCC55 -DCCTYPE=BORLAND -DINST_DRV=P: --- - F F -Duseithreads -Duselargefiles | +- -DDEBUGGING +--- no debugging Failures: (common-args) -DCCHOME=C:\Borland\BCC55 -DCCTYPE=BORLAND -DINST_DRV=P: [default] -Duseithreads -Duselargefiles [default] -DDEBUGGING -Duseithreads -Duselargefiles ../lib/Time/Local.t.FAILED 97-120 Weird. I just tried a smoke with the same version of Borland and the same configurations of perl, and got success: http://www.nntp.perl.org/group/perl.daily-build.reports/29840 The only difference is a few patch levels (which I don't think is relevant) and the OS -- I'm using Win XP. I don't have Win 2000 machine on which I can take a closer look at this. I see that your VC++ smokes on the same Win 2000 machine are successful, though, so it looks like some strange issue with bcc32 + Win 2000. Do you have a Win XP machine that you could try the bcc32 smoke on to confirm that? Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
RE: [EMAIL PROTECTED] - ext/Compress/Zlib on VMS.
From: John E. Malmberg [mailto:[EMAIL PROTECTED]
The script 03examples.t is failing at test 1 because the includes seem
to be set wrong for VMS.
--- ext/compress/zlib/t/03examples_t.blead Sun Jul 31 22:54:06 2005
+++ ext/compress/zlib/t/03examples.tSun Jul 31 22:54:12 2005
@@ -42,7 +42,7 @@
my $Inc = '' ;
if ($^O eq 'VMS') {
- $Inc = '-I[.blib.lib] -I[.blib.arch]';
+ $Inc = '-I[-.lib] -I[-.arch]';
}
elsif ($^O eq 'MSWin32') {
foreach (@INC)
Is this the layout needed for running these tests when Compress::Zlib is in
the core only? Is the use of blib still valid for the case when C::Z is
built on VMS away from the core?
This gets the script passing up to test 10 which causes the subsequent
tests to fail.
Test 10 triggers the perl interface to the zlib function gzdopen. This is
one of the non-portable hot-spots in Compress::Zlib (and is reworked
completely in the next version of Compress::Zlib).
DB5 x `$Perl $Inc ${examples}/gzstream $file1 $file2 2$stderr`
The error captured in the file $stderr is:
EAGLE type err.out
Cannot open stdout: invalid argument
%C-F-EINVAL, invalid argument
The value for stdout should have been the filename hello2.gz, and there
should be nothing illegal about that. I will need to chase that down
later, if someone else does not find the fix before this.
Unless VMS works completely differently to Unix-land, that isn't the case.
The code that is triggering the error is this:
my $gz = gzopen(\*STDOUT, wb)
or die Cannot open stdout: $gzerrno\n ;
I'm passing the STDOUT filehandle into gzopen, not the hello2.gz filename.
That in turn calls this code in Zlib.pm (where $file is the STDOUT
filehandle)
IO::Handle::flush($file) ;
my $offset = tell($file) ;
gzdopen_(fileno($file), $mode, $offset) ;
The gzdopen_ call is where I interface to the zlib gzdopen 'C' function.
Does VMS allow this messing with the STDOUT filehandle?
Paul
___
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com
Re: [EMAIL PROTECTED] - ext/Compress/Zlib on VMS.
Paul Marquess wrote:
- $Inc = '-I[.blib.lib] -I[.blib.arch]';
+ $Inc = '-I[-.lib] -I[-.arch]';
}
elsif ($^O eq 'MSWin32') {
foreach (@INC)
Is this the layout needed for running these tests when Compress::Zlib is in
the core only? Is the use of blib still valid for the case when C::Z is
built on VMS away from the core?
That's possible, but blib should take care of that IIRC. (non-core builds)
Smoke [5.9.3] 25250 FAIL(XF) bsd/os 4.1 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25250 fixit.xs4all.nl: Pentium II (i386/1 cpu) onbsd/os - 4.1 using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release) smoketime 3 hours 55 minutes (average 1 hour 57 minutes) Summary: FAIL(XF) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25250 Configuration (common) none --- - F F - - -Duse64bitint X O - - | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio] -Duse64bitint ../t/op/int.t...FAILED 11 [perlio] -Duse64bitint ../lib/Net/hostent.tFAILED 4-7 ../t/op/int.t...FAILED 11 [stdio] Inconsistent test results (between TEST and harness): ../lib/Net/hostent.tFAILED at test 4 -- Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503 (Reporter v0.019 / Smoker v0.023)
Re: [EMAIL PROTECTED] - ext/Compress/Zlib on VMS.
Rafael Garcia-Suarez wrote:
Paul Marquess wrote:
- $Inc = '-I[.blib.lib] -I[.blib.arch]';
+ $Inc = '-I[-.lib] -I[-.arch]';
}
elsif ($^O eq 'MSWin32') {
foreach (@INC)
Is this the layout needed for running these tests when Compress::Zlib is in
the core only? Is the use of blib still valid for the case when C::Z is
built on VMS away from the core?
That's possible, but blib should take care of that IIRC. (non-core builds)
I am kind of new at working on Perl if that was not obvious.
From what I have seen of the other tests, the INC setting when running
these tests is usually inherited from the parent, and I have seen the
tests use a test when deciding to use blib or not.
I did not know the correct fix, just what I needed to stop the script
from failing so soon. The [-.lib] was the only place that I could find
the modules. That is also the setting that was passed on the command
line to 03examples.t.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: [EMAIL PROTECTED] - ext/Compress/Zlib on VMS.
Paul Marquess wrote:
From: John E. Malmberg [mailto:[EMAIL PROTECTED]
The script 03examples.t is failing at test 1 because the includes seem
to be set wrong for VMS.
snip - answered in previous discussion
This gets the script passing up to test 10 which causes the subsequent
tests to fail.
Test 10 triggers the perl interface to the zlib function gzdopen. This is
one of the non-portable hot-spots in Compress::Zlib (and is reworked
completely in the next version of Compress::Zlib).
DB5 x `$Perl $Inc ${examples}/gzstream $file1 $file2 2$stderr`
The error captured in the file $stderr is:
EAGLE type err.out
Cannot open stdout: invalid argument
%C-F-EINVAL, invalid argument
The value for stdout should have been the filename hello2.gz, and there
should be nothing illegal about that. I will need to chase that down
later, if someone else does not find the fix before this.
Unless VMS works completely differently to Unix-land, that isn't the case.
The code that is triggering the error is this:
In this case it does. The input and output redirections on the command
line are handled by VMS specific code in the Perl binary, not by the
shell. There are probably other significant differences.
my $gz = gzopen(\*STDOUT, wb)
or die Cannot open stdout: $gzerrno\n ;
I'm passing the STDOUT filehandle into gzopen, not the hello2.gz filename.
That in turn calls this code in Zlib.pm (where $file is the STDOUT
filehandle)
IO::Handle::flush($file) ;
my $offset = tell($file) ;
gzdopen_(fileno($file), $mode, $offset) ;
The gzdopen_ call is where I interface to the zlib gzdopen 'C' function.
Does VMS allow this messing with the STDOUT filehandle?
I do not know. I will need to do more investigations to find out why it
is failing, what I will have to do is find the actual C code that is
being processed.
Also, VMS has many internal file structures. GZIP and TAR can
effectively only work on to classes of files, STREAM and BINARY. For
the other types, information that is stored in the file header is not
preserved in the compressed file or archive anywhere, and with out that
information, there is no way to restore most files.
The natural text file format of VMS is known as VFC, which has a byte
count at the beginning of each record. STDIN, STDERR, and STDOUT are
normally text files.
I can think of two ways that TAR/GZIP can handle all VMS file types.
Either add an extra made up file that has the file header information,
or encode the file header information in the stored filename. Of course
that means that what ever restores the file on VMS would have to know
what is going on.
So this will take some investigation on a VMS system to see what the
real problem is.
-John
[EMAIL PROTECTED]
Personal Opinion Only
[PATCH] perldoc -m switch strange behaviour (or a little bug? :-) )
Hi all, during development of POD2::IT translation project, I've looked more in deep the (excellent) Pod::Perldoc package. Since we've proposed also a patch to perldoc in order to integrate it with generic pod translations package (not only italian), we've tested all switches with the new one -L language_code. We've seen that ther's a strange behaviour with -m switch (it shows file in its entirety). In particular: % perldoc -m perlboot works well (in general with all core pods). But for example: % perldoc -m lwpcook doesn't work and: % perldoc lwpcook does work! (of course, with the last two you must have LWP installed in your system). In a few words: Pod/Perldoc.pm adds also .pod extension (to perldoc argument) only if: 1) -m switch hasn't been specified or 2) only for 'pod/' or 'pods/' subdirectory (indipendently from -m switch presence). Sincerely, I don't know if there's a directive and/or specification and/or a reason that suggests to put *.pod files (shipped in a distribution) into a pod/ or pods/ subdirectory, but there are many CPAN modules that don't do it! :-) So, I think that the !$self-opt_m condition at the line 1537 of Pod/Perldoc.pm could be omitted. I've included a very simple patch over Pod/Perldoc.pm 3.14 by - Enrico Perldoc.pm-3.14-switchm_patch Description: Binary data
Re: [EMAIL PROTECTED] on OpenVMS (not good)
Rafael Garcia-Suarez wrote: John E. Malmberg wrote: This requires fixing in multiple places. perl.h, util.c, and embed.fnc, and this seems to require a running perl to rebuild proto.h Thanks, applied as change #25251. Change #25218 needs to be backed out. Adding the (char *) cast to suppress a the compiler warning changes a build time error in to several potential run time errors, including access violations and data corruptions. Patch 25217, while making the code build, has the same bug in it. The patches for perl/pp_sys.c, pp_ctl.c, and mg.c contained in it are incorrect and should eventually cause runtime corruption or access violations. I previously submitted patches that fix the problem correctly. The way that Perl uses this type of memory, the data corruption is likely to be rare and hard to diagnose. The access violations may also be rare, but when they happen they will be obvious. Look with great suspicion on any code that is using a cast to get around a NON-CONST Qualified error. There are only a few cases where that is valid to do, and that is where you are setting up a structure to be passed to a read-only argument. While the code involved in all these cases in Perl is VMS specific, this handling of const qualified variables is not a VMS specific issue. This was not a case of the compiler being too picky, it was flagging a significant bug. -John [EMAIL PROTECTED] Personal Opinion Only
RE: [EMAIL PROTECTED] - ext/Compress/Zlib on VMS.
From: Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED]
Paul Marquess wrote:
- $Inc = '-I[.blib.lib] -I[.blib.arch]';
+ $Inc = '-I[-.lib] -I[-.arch]';
}
elsif ($^O eq 'MSWin32') {
foreach (@INC)
Is this the layout needed for running these tests when Compress::Zlib is
in
the core only? Is the use of blib still valid for the case when C::Z is
built on VMS away from the core?
That's possible, but blib should take care of that IIRC. (non-core builds)
Sorry, I don't think I was very clear. When I said to use blib, I didn't
mean -Mblib, but to use the previous code that checked the blib directory
$Inc = '-I[.blib.lib] -I[.blib.arch]'
So should the change be something like this to allow the module to be
installed with the core and standalone?
if ($^O eq 'VMS') {
if (INCORE ) {
$Inc = '-I[-.lib] -I[-.arch]';
}
else {
$Inc = '-I[.blib.lib] -I[.blib.arch]';
}
}
Where INCORE figures out which incpath to use.
Paul
___
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com
Re: [patch] [EMAIL PROTECTED] on OpenVMS/vms.c - fopen bug.
John E. Malmberg wrote: The existing code in the fopen() call aways fails with an invalid argument, so the if clause following it has never been run since this version of the code was in place. Fixing this bug may expose other side effects as it is assuming that the first 4 bytes of an executable are not printable. I have not checked if that is true for the ELF executables found on I64. EAGLE gdiff -u vms/vms.c_bug2 vms/vms.c --- vms/vms.c_bug2 Fri Jul 29 10:15:32 2005 +++ vms/vms.c Fri Jul 29 10:14:03 2005 @@ -5300,7 +5300,7 @@ *s = '\0'; /* check that it's really not DCL with no file extension */ - fp = fopen(resspec,r,ctx=bin,shr=get); + fp = fopen(resspec,r,ctx=bin,shr=get); Thanks, applied to bleadperl as change #25255.
Re: [EMAIL PROTECTED] on OpenVMS (not good)
John E. Malmberg wrote: Change #25218 needs to be backed out. Adding the (char *) cast to suppress a the compiler warning changes a build time error in to several potential run time errors, including access violations and data corruptions. Patch 25217, while making the code build, has the same bug in it. The patches for perl/pp_sys.c, pp_ctl.c, and mg.c contained in it are incorrect and should eventually cause runtime corruption or access violations. I previously submitted patches that fix the problem correctly. I think I've applied them correctly as change #25257, including backing out the patches you mentioned. http://public.activestate.com/cgi-bin/perlbrowse?patch=25257 (not having access to a VMS box, and being a bit in a hurry since I'll be leaving soon for OSCON, it would be useful if you check that I've not messed it up completely.)
Re: [PATCH] POD typos
Rafael Garcia-Suarez [EMAIL PROTECTED] writes: Piotr Fusik wrote: I've extracted a list of words from all the PODs and spell-checked it. The result is in the attachment. Thanks, applied, except bits that touch dual-live modules. I applied the changes to the development tree of Getopt::Long, so they will not get lost when a new version is taken into production. -- Johan
Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!
Michael G Schwern wrote: So it sounds like the resolution for this bug is to document that sort uses aliases like grep does. I've stolen the wording from grep. Thanks, applied as change #25258.
Smoke [5.9.3] 25248 FAIL(F) openbsd 3.7 (i386/1 cpu)
Automated smoke report for 5.9.3 patch 25248 mccoy.peters.homeunix.org: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) (548 MHz) (i386/1 cpu) onopenbsd - 3.7 using cc version 3.3.5 (propolice) smoketime 8 hours 36 minutes (average 1 hour 4 minutes) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25248 Configuration (common) none --- - F F F F F F F F -Duse64bitint F F F F -Duseithreads F F F F -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] [stdio/perlio] -DDEBUGGING [stdio/perlio] -Duse64bitint [stdio/perlio] -DDEBUGGING -Duse64bitint [stdio/perlio] -Duseithreads [stdio/perlio] -DDEBUGGING -Duseithreads [stdio/perlio] -Duseithreads -Duse64bitint [stdio/perlio] -DDEBUGGING -Duseithreads -Duse64bitint ../t/op/sprintf.t...FAILED 147 Compiler messages(gcc): /tmp//ccRxb614.o(.text+0x3e): In function `main': /tmp//ccQ13941.o(.text+0x5d): In function `main': /tmp//cca23652.o(.text+0xde): In function `main': op.c: In function `Perl_newCONSTSUB': op.c:4611: warning: null argument where non-null required (arg 1) opmini.c: In function `Perl_newCONSTSUB': opmini.c:4611: warning: null argument where non-null required (arg 1) libperl.a(perlio.o)(.text+0x4ed8): In function `PerlIO_vsprintf': opmini.o(.text+0x316): In function `Perl_allocmy': libperl.a(toke.o)(.text+0x722c): In function `Perl_yylex': libperl.a(op.o)(.text+0x316): In function `Perl_allocmy': lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x23e): In function `XS_DynaLoader_dl_load_file': util.o(.text+0x1f3): In function `savestr': str.o(.text+0x5d): In function `str_2ptr': byterun.c: In function `byterun': byterun.c:893: warning: comparison is always false due to limited range of data type ../libperl.a(perlio.o)(.text+0x4ed8): In function `PerlIO_vsprintf': ../libperl.a(op.o)(.text+0x316): In function `Perl_allocmy': ../libperl.a(toke.o)(.text+0x722c): In function `Perl_yylex': /tmp//ccp28709.o(.text+0x3e): In function `main': /tmp//ccx28812.o(.text+0x5d): In function `main': /tmp//ccl27392.o(.text+0xde): In function `main': libperl.a(perlio.o)(.text+0x4f98): In function `PerlIO_vsprintf': libperl.a(toke.o)(.text+0x7f30): In function `Perl_yylex': lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x326): In function `XS_DynaLoader_dl_load_file': util.o(.text+0x2c3): In function `savestr': str.o(.text+0x81): In function `str_2ptr': ../libperl.a(perlio.o)(.text+0x4f98): In function `PerlIO_vsprintf': ../libperl.a(toke.o)(.text+0x7f30): In function `Perl_yylex': /tmp//ccul8271.o(.text+0x3e): In function `main': /tmp//ccL26524.o(.text+0x5d): In function `main': /tmp//ccp20819.o(.text+0xde): In function `main': libperl.a(perlio.o)(.text+0x52f4): In function `PerlIO_vsprintf': libperl.a(toke.o)(.text+0x7330): In function `Perl_yylex': ../libperl.a(perlio.o)(.text+0x52f4): In function `PerlIO_vsprintf': ../libperl.a(toke.o)(.text+0x7330): In function `Perl_yylex': /tmp//ccqJ1449.o(.text+0x3e): In function `main': /tmp//ccQq6087.o(.text+0x5d): In function `main': /tmp//ccB14186.o(.text+0xde): In function `main': libperl.a(perlio.o)(.text+0x53b4): In function `PerlIO_vsprintf': libperl.a(toke.o)(.text+0x8030): In function `Perl_yylex': lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x32a): In function `XS_DynaLoader_dl_load_file': ../libperl.a(perlio.o)(.text+0x53b4): In function `PerlIO_vsprintf': ../libperl.a(toke.o)(.text+0x8030): In function `Perl_yylex': /tmp//ccJ22655.o(.text+0x3e): In function `main': /tmp//ccf20406.o(.text+0x5d): In function `main': /tmp//ccm31490.o(.text+0xde): In function `main': libperl.a(perlio.o)(.text+0x127): In function `PerlIO_debug': opmini.o(.text+0x39d): In function `Perl_allocmy': libperl.a(toke.o)(.text+0x8060): In function `Perl_yylex': libperl.a(op.o)(.text+0x39d): In function `Perl_allocmy': lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x302): In function `XS_DynaLoader_dl_load_file': DProf.xs:140: warning: `unused' attribute ignored ../libperl.a(perlio.o)(.text+0x127): In function `PerlIO_debug': ../libperl.a(op.o)(.text+0x39d): In function `Perl_allocmy': ../libperl.a(toke.o)(.text+0x8060): In function `Perl_yylex': /tmp//ccV13334.o(.text+0x3e): In function `main': /tmp//ccJA9839.o(.text+0x5d): In function `main': /tmp//cci28480.o(.text+0xde): In function `main': libperl.a(toke.o)(.text+0x8ed0): In function `Perl_yylex': lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o)(.text+0x4f6): In function `XS_DynaLoader_dl_load_file':
Re: Smoke [5.9.3] 25248 FAIL(F) openbsd 3.7 (i386/1 cpu)
On Mon, Aug 01, 2005 at 10:41:00AM -0500, [EMAIL PROTECTED] wrote: Automated smoke report for 5.9.3 patch 25248 mccoy.peters.homeunix.org: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) (548 MHz) (i386/1 cpu) onopenbsd - 3.7 using cc version 3.3.5 (propolice) smoketime 8 hours 36 minutes (average 1 hour 4 minutes) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25248 Configuration (common) none --- - F F F F F F F F -Duse64bitint F F F F -Duseithreads F F F F -Duseithreads -Duse64bitint | | | +- PERLIO = perlio -DDEBUGGING | | +--- PERLIO = stdio -DDEBUGGING | +- PERLIO = perlio +--- PERLIO = stdio Failures: (common-args) none [stdio/perlio] [stdio/perlio] -DDEBUGGING [stdio/perlio] -Duse64bitint [stdio/perlio] -DDEBUGGING -Duse64bitint [stdio/perlio] -Duseithreads [stdio/perlio] -DDEBUGGING -Duseithreads [stdio/perlio] -Duseithreads -Duse64bitint [stdio/perlio] -DDEBUGGING -Duseithreads -Duse64bitint ../t/op/sprintf.t...FAILED 147 It appears that the additional sprintf.t test is causing failures on OpenBSD. ok 142 ok 143 ok 144 ok 145 ok 146 not ok 147 %.0g -0.0 -0 0 # No minus ok 148 ok 149 ok 150 ok 151 Steve Peters [EMAIL PROTECTED]
Re: Smoke [5.9.3] 25248 FAIL(F) openbsd 3.7 (i386/1 cpu)
On 2005–08–01, at 17:45, Steve Peters wrote:
Automated smoke report for 5.9.3 patch 25248
mccoy.peters.homeunix.org: Intel Pentium III (GenuineIntel 686-
class, 512KB L2 cache) (548 MHz) (i386/1 cpu)
onopenbsd - 3.7
using cc version 3.3.5 (propolice)
...
It appears that the additional sprintf.t test is causing failures
on OpenBSD.
ok 142
ok 143
ok 144
ok 145
ok 146
not ok 147 %.0g -0.0 -0 0 # No minus
ok 148
ok 149
ok 150
ok 151
3.7 is the latest openbsd, isn't it? Presumably gcc 3.3.5 is the
default C compiler for this version. Can you say how the tests look
if you use gcc 4.0 instead of 3.3.5?
If gcc 4.0 does not fix the problem, and if it is reasonable to
expect most people to build perl for openbsd 3.7 using gcc 3.3.5, can
you cook up and test a patch for the relevant line of sprintf.t, such
that openbsd is added to the skip list? If you feel optimistic about
a fix appearing in the next release of openbsd, limit the skip to
v3.7 and earlier; otherwise skip for all versions.
As I think this is a divergence from the C standard*, can you report
it as a bug to the openbsd people? My (cursory) search of their
problem reports does not turn up anything that looks close to this
issue. The following test program should output -0. Well, it does
for me on Mac OS X, anyway:
#include math.h
#include stdio.h
main(){printf(%g\n, -pow(10, -200) * pow(10, -200));}
(Identity cribbed from http://www.savrola.com/resources/
negative_zero.html.)
Thanks for your help.
* The results of all floating conversions of a negative zero, and of
negative values that round to zero, include a minus sign. --
footnote in section 7.19.6.1, sprintf, of ISO 9899:1999 --
Programming Language C.
--
Dominic Dunlop
Re: Smoke [5.9.3] 25245 FAIL(F) MSWin32 Win2000 SP4 (x86/1 cpu)
[sorry, no mail on this box] Steve Hay wrote: Abe Timmerman wrote: Op een mooie zomerdag (Friday 29 July 2005 21:11),schreef Abe Timmerman: Automated smoke report for 5.9.3 patch 25245 neewa: x86 Family 6 Model 5 Stepping 2(~450 MHz) (x86/1 cpu) onMSWin32 - Win2000 SP4 using bcc32 version 5.5.1 smoketime 2 hours 13 minutes (average 1 hour 6 minutes) X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Summary: FAIL(F) ... ../lib/Time/Local.t.FAILED 97-120 Weird. I just tried a smoke with the same version of Borland and the same configurations of perl, and got success: http://www.nntp.perl.org/group/perl.daily-build.reports/29840 The only difference is a few patch levels (which I don't think is relevant) and the OS -- I'm using Win XP. I don't have Win 2000 machine on which I can take a closer look at this. I see that your VC++ smokes on the same Win 2000 machine are successful, though, so it looks like some strange issue with bcc32 + Win 2000. I'm afraid not :-( Do you have a Win XP machine that you could try the bcc32 smoke on to confirm that? Automated smoke report for 5.9.3 patch 25260 ati4: Intel(R) Pentium(R) 4 CPU 2.80GHz(~2793 MHz) (x86/2 cpu) onMSWin32 - WinXP/.Net SP2 using bcc32 version 5.5.1 smoketime 39 minutes 42 seconds (average 19 minutes 51 seconds) Summary: FAIL(F) O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 25260 Configuration (common) -DCCHOME=C:\Borland\BCC55 -DCCTYPE=BORLAND -DINST_DRV=P: --- - F F -Duseithreads -Duselargefiles | +- -DDEBUGGING +--- no debugging Locally applied patches: DEVEL24148 Failures: (common-args) -DCCHOME=C:\Borland\BCC55 -DCCTYPE=BORLAND -DINST_DRV=P: [default] -Duseithreads -Duselargefiles [default] -DDEBUGGING -Duseithreads -Duselargefiles ../lib/Time/Local.t.FAILED 97-120 -- Abe.
Re: [perl #22758] debugger command |x swallows all output
On 12 Jul 2005 at 16:19, Michael G Schwern via RT wrote: [EMAIL PROTECTED] - Sun Jun 22 23:53:28 2003]: - The debugger command x works as expected, but |x shows no output at all: I am unable to reproduce this problem. What pager does the debugger think you're using? You can find out with this: $ perl -de 1 Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): 1 DB1 print DB::pager |/usr/bin/less main::(-e:1): 1 DB1 print DB::pager |less So maybe it's the missting fully qualified name. Shouldn't perl print some diagnostics if the pager cannot be found? BTW: I tried (not sure which configuration I had reported the problem): mailgate:/var/tmp # PATH= /usr/bin/perl -de 1 Loading DB routines from perl5db.pl version 1.27 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(-e:1): 1 DB1 @a=(1 .. 17) DB2 x @a 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 11 11 12 12 13 13 14 14 15 15 16 16 17 DB3 |x @a [1]+ Stopped PATH= /usr/bin/perl -de 1 (Perl seems to hang here) Regards, Ulrich
t/op/tr failing on EBCDIC Platform.
Hi Can somebody enlighten me how the transliteration operator (tr//) is supposed to work on EBCDIC platform? I am asking this question with reference to a test case in perl-5.8.6 i.e t/op/tr which is failing on EBCDIC platform Here is the snipped of the test case ... # Tricky on EBCDIC: while [a-z] [A-Z] must not match the gap characters, # (i-j, r-s, I-J, R-S), [\x89-\x91] [\xc9-\xd1] has to match them, # from Karsten Sperling. # Not working in EBCDIC as of 12674. $c = ($a = \x89\x8a\x8b\x8c\x8d\x8f\x90\x91) =~ tr/\x89-\x91/X/; is($c, 8); is($a, ); # Not working in EBCDIC as of 12674. $c = ($a = \xc9\xca\xcb\xcc\xcd\xcf\xd0\xd1) =~ tr/\xc9-\xd1/X/; is($c, 8); is($a, ); ... Is it supposed to change the gapped characters to X also? In that case what is the behaviour for tr/a-z/X ? Thanks in advance Sastry
[perl #36741] perl build switchable compatible arch name?
# New Ticket Created by Auke Kok # Please include the string: [perl #36741] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36741 Hi, Not sure if this is a BUILD bug but it certainly is a nuisance and should be a lot easier: I'm trying to build perl on a i686 machine for i386. Since all my software is optimized for i386 this should not pose a problem, however perl refuses to see (even when passed the many -Dtarch -Dtargetarch options) my i386 and assumes i686, which results in an improper build (gcc nicely is even installed as i386). $BUILD is also set accordingly. The current fix I'll be using is to replace /bin/arch with a script that does `echo i386`. This is very ugly. Can the Configure script of perl be adjusted so that it is possible to _set_ the arch to i386 ? Thanks. Auke Kok
Re: Smoke [5.9.3] 25248 FAIL(F) openbsd 3.7 (i386/1 cpu)
Op een mooie zomerdag (Monday 01 August 2005 18:51),schreef Dominic Dunlop:
On 2005–08–01, at 17:45, Steve Peters wrote:
Automated smoke report for 5.9.3 patch 25248
mccoy.peters.homeunix.org: Intel Pentium III (GenuineIntel 686-
class, 512KB L2 cache) (548 MHz) (i386/1 cpu)
onopenbsd - 3.7
using cc version 3.3.5 (propolice)
...
It appears that the additional sprintf.t test is causing failures
on OpenBSD.
...
not ok 147 %.0g -0.0 -0 0 # No minus
...
3.7 is the latest openbsd, isn't it? Presumably gcc 3.3.5 is the
default C compiler for this version. Can you say how the tests look
if you use gcc 4.0 instead of 3.3.5?
If gcc 4.0 does not fix the problem, and if it is reasonable to
expect most people to build perl for openbsd 3.7 using gcc 3.3.5, can
you cook up and test a patch for the relevant line of sprintf.t, such
that openbsd is added to the skip list? If you feel optimistic about
a fix appearing in the next release of openbsd, limit the skip to
v3.7 and earlier; otherwise skip for all versions.
It looks like there's more than windows and openbsd3.7:
http://www.test-smoke.org/cgi/tsdb?fososver=1farch=1frtext=1rtext=failed+147pversion=5.9.3plcmp=fromlmode=List+reports
(sorry, it's slow)
As I think this is a divergence from the C standard*, can you report
it as a bug to the openbsd people? My (cursory) search of their
problem reports does not turn up anything that looks close to this
issue. The following test program should output -0. Well, it does
for me on Mac OS X, anyway:
#include math.h
#include stdio.h
main(){printf(%g\n, -pow(10, -200) * pow(10, -200));}
(Identity cribbed from http://www.savrola.com/resources/
negative_zero.html.)
Thanks for your help.
* The results of all floating conversions of a negative zero, and of
negative values that round to zero, include a minus sign. --
footnote in section 7.19.6.1, sprintf, of ISO 9899:1999 --
Programming Language C.
Good luck,
Abe
--
This thread is supposed to be about what it means - not about the
implementation. I am painfully aware of the implementation issues.
-- Nick Ing-Simmons on p5p @ 2003-05-22
p5p++ party
What started life as the perl5-porters party has grown into more of a FONT party (Friends Of Nat Torkington), but at its heart are still the p5p folks. If you're on this list, consider yourself invited: Room 1555, Doubletree Hotel, Portland OR 8:00pm- Thursday August 4th. Eat dinner before you come. We'll lay on dessert and drinks, but feel free to bring your own as well. There will be kids, alcohol, and conversation. If you're uncomfortable around any of these, you probably should think twice about coming :-) Cheers; Nat
[EMAIL PROTECTED] on OpenVMS still not building
Hi all, The build stops here: Running Mkbootstrap for B::C () MCR BLDROOT:[00]miniperl.exe -I[---.lib] -I[---.lib] -MExtUtils::Comman d -e chmod 644 C.BS MCR BLDROOT:[00]miniperl.exe -I[---.lib] -I[---.lib] -MExtUtils::Comman d -e cp C.bs [---.LIB.AUTO.B.C]C.BS MCR BLDROOT:[00]miniperl.exe -I[---.lib] -I[---.lib] -MExtUtils::Comman d -e chmod 644 [---.LIB.AUTO.B.C]C.BS %MMS-F-ABORT, For target SUBDIRS, CLI returned abort status: %X10EE8180. %MMS-F-ABORT, For target DYNEXT, CLI returned abort status: %X10EE8034. HTH + Good luck, Abe -- Let's not cloud the issue with facts, shall we? -- Jarkko Hietaniemi on p5p @ 2003-05-02
[patch]vms.c - buffer highwater overrun in vmsify
This bug is in the routine mp_to_vmsspec(). If it is passed a name like
/foo where foo is a logical name, with no other directories or file
names in the path, after the translation, the null terminator was always
being skipped over, and what ever was previously in that memory would
get concatenated to the string.
The result would usually be an unusable string.
As I fix the UNIX name handling elsewhere in the VMS specific parts of
perl to remove the /00 that should not be there, it may make this
bug more visible.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- vms/vms.c_blead Mon Aug 1 19:37:03 2005
+++ vms/vms.c Mon Aug 1 19:36:56 2005
@@ -3842,8 +3842,10 @@
if (!buf ts) Renew(rslt,strlen(path)-strlen(rslt)+trnend+4,char);
strcpy(rslt,trndev);
cp1 = rslt + trnend;
-*(cp1++) = '.';
-cp2++;
+ if (*cp2 != 0) {
+ *(cp1++) = '.';
+ cp2++;
+}
}
else {
*(cp1++) = ':';
Re: [EMAIL PROTECTED] - ext/Compress/Zlib on VMS.
John E. Malmberg wrote:
Rafael Garcia-Suarez wrote:
Paul Marquess wrote:
- $Inc = '-I[.blib.lib] -I[.blib.arch]';
+ $Inc = '-I[-.lib] -I[-.arch]';
}
elsif ($^O eq 'MSWin32') {
foreach (@INC)
Is this the layout needed for running these tests when Compress::Zlib
is in
the core only? Is the use of blib still valid for the case when C::Z is
built on VMS away from the core?
That's possible, but blib should take care of that IIRC. (non-core
builds)
I am kind of new at working on Perl if that was not obvious.
From what I have seen of the other tests, the INC setting when running
these tests is usually inherited from the parent, and I have seen the
tests use a test when deciding to use blib or not.
I did not know the correct fix, just what I needed to stop the script
from failing so soon. The [-.lib] was the only place that I could find
the modules. That is also the setting that was passed on the command
line to 03examples.t.
Is there really any reason that there is VMS specific code here?
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: [EMAIL PROTECTED] on OpenVMS (not good)
Rafael Garcia-Suarez wrote: I think I've applied them correctly as change #25257, including backing out the patches you mentioned. http://public.activestate.com/cgi-bin/perlbrowse?patch=25257 (not having access to a VMS box, and being a bit in a hurry since I'll be leaving soon for OSCON, it would be useful if you check that I've not messed it up completely.) I just checked the files for the edits, I have not run a newer build. vms/vms.c - ok. vms/vmsish.h - ok perl.h - ok embed.fnc - ok util.c - ok mg.c - ok vms/descrip_mms.template - patch not yet applied. With out this patch, the debug build produces large listings that do not really have any usable content. -John [EMAIL PROTECTED] Personal Opinion Only
Re: [EMAIL PROTECTED] on OpenVMS still not building
Abe Timmerman wrote: Hi all, The build stops here: Running Mkbootstrap for B::C () MCR BLDROOT:[00]miniperl.exe -I[---.lib] -I[---.lib] -MExtUtils::Comman d -e chmod 644 C.BS MCR BLDROOT:[00]miniperl.exe -I[---.lib] -I[---.lib] -MExtUtils::Comman d -e cp C.bs [---.LIB.AUTO.B.C]C.BS MCR BLDROOT:[00]miniperl.exe -I[---.lib] -I[---.lib] -MExtUtils::Comman d -e chmod 644 [---.LIB.AUTO.B.C]C.BS %MMS-F-ABORT, For target SUBDIRS, CLI returned abort status: %X10EE8180. %MMS-F-ABORT, For target DYNEXT, CLI returned abort status: %X10EE8034. Unfortunately I can not translate those status codes to anything, which means that facility is not on my ALPHA system. All the patches that I know of for vms.c have been applied, except for the one that I just posted, and I do not think it is affecting you. I do not have time to do a build of 25260 tonight, I want to get some minor patches submitted for some other things that I have found while getting the UNIX mode of VMS to work. Chasing this down will require finding the exact command that is aborting for target SUBDIRS. -John [EMAIL PROTECTED] Personal Opinion Only
Re: [PATCH] POD typos
On Mon, Aug 01, 2005 at 10:42:46AM +0200, Rafael Garcia-Suarez wrote: Piotr Fusik wrote: I've extracted a list of words from all the PODs and spell-checked it. The result is in the attachment. Thanks, applied, except bits that touch dual-live modules. I've applied the fixes from both his spell check packages to Test-Simple and ExtUtils-MakeMaker. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
[patch] [EMAIL PROTECTED] - VMS specific fixes.
Here are some miscellaneous VMS specific things that need to be fixed
for VMS to work with the VMS C Run-Time Library (CRTL) UNIX filename
mode that do not require any other changes to Perl for implementation.
When the VMS CRTL is in UNIX filename mode, the VMS C library calls
return filenames in UNIX format.
Sorry if I got the case of some of the filenames wrong. I tried to get
them right.
t/op/anonsub.t :
t/op/closure.t :
t/op/lex_assign.t :
t/op/runlevel.t :
t/lib/warnings/doio :
lib/Test/Harness/Straps.pm :
Remove 'MCR'. It is not needed, and it breaks Perl when the VMS CRTL is
in UNIX filename mode. PERL on VMS usually knows when to add the MCR
command and how to handle $^X as either a VMS or UNIX file specification.
lib/vmsish.t:
vms/ext/Stdio/test.pl:
MCR is still needed in these cases, but must make sure that $^X is a VMS
file specification if MCR is prefixing it.
utils/c2ph.pl :
VMS now supports LINK, but still uses a different filename. Since link
is configured, the link routine is expected to succeed. Note that not
all file systems on VMS support the link(), but we are assuming that if
someone built a binary with link(), they are building on a file system
with link support on.
t/op/chdir.t
Clean up SYS$LOGIN after this script is run out side of the test
harness. A bit strange to exit a script and find the pointer to the
login directory gone.
t/op/stat.t
Perl could find a /bin/ls on VMS but not really know how to run it yet,
resulting in some interesting test failures.
t/x2p/s2p.t
RMSEXPAND needs a VMS format file specification. When the VMS CRTL is
in UNIX filename mode, these additional vmsify() commands are needed.
t/pod/find.t
VMS could be in a UNIX filename mode, so if you want a filename in VMS
format, it needs to be converted.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- t/op/anonsub.t_bleadMon Aug 1 21:04:15 2005
+++ t/op/anonsub.t Mon Aug 1 21:04:22 2005
@@ -32,7 +32,7 @@
print TEST $prog\n;
close TEST or die Could not close: $!;
my $results = $Is_VMS ?
- `MCR $^X -I[-.lib] $switch $tmpfile 21` :
+ `$^X -I[-.lib] $switch $tmpfile 21` :
$Is_MSWin32 ?
`.\\perl -I../lib $switch $tmpfile 21` :
$Is_MacOS ?
--- utils/c2ph.pl Mon Aug 1 22:15:46 2005
+++ utils/c2ph.pl_blead Mon Aug 1 22:12:34 2005
@@ -1437,7 +1437,7 @@
unlink 'pstruct';
print Linking c2ph to pstruct.\n;
if (defined $Config{d_link}) {
- link $file, 'pstruct';
+ link 'c2ph', 'pstruct';
} else {
unshift @INC, '../lib';
require File::Copy;
--- t/op/chdir.t_blead Mon Aug 1 22:24:46 2005
+++ t/op/chdir.tMon Aug 1 22:24:24 2005
@@ -138,6 +138,10 @@
# Restore the environment for VMS (and doesn't hurt for anyone else)
@[EMAIL PROTECTED] = @[EMAIL PROTECTED];
+
+# On VMS this must be deleted or process table is wrong on exit
+# when this script is run interactively.
+delete $ENV{'SYS$LOGIN'} if $IsVMS;
}
--- t/op/closure.t_bleadMon Aug 1 22:30:08 2005
+++ t/op/closure.t Mon Aug 1 22:30:14 2005
@@ -466,7 +466,7 @@
my $errfile = terr$$; $errfile++ while -e $errfile;
my @tmpfiles = ($cmdfile, $errfile);
open CMD, $cmdfile; print CMD $code; close CMD;
- my $cmd = (($^O eq 'VMS') ? MCR $^X
+ my $cmd = (($^O eq 'VMS') ? $^X
: ($^O eq 'MSWin32') ? '.\perl'
: ($^O eq 'MacOS') ? $^X
: ($^O eq 'NetWare') ? 'perl'
--- t_lib_warnings_doio.blead Mon Aug 1 22:39:42 2005
+++ t/lib/warnings/doio.Mon Aug 1 22:40:25 2005
@@ -60,10 +60,10 @@
__END__
# doio.c [Perl_do_open9]
use warnings 'io' ;
-open(F, '|'.($^O eq 'VMS' ? 'mcr ':'').$^X -e 1|);
+open(F, '|'.$^X -e 1|);
close(F);
no warnings 'io' ;
-open(G, '|'.($^O eq 'VMS' ? 'mcr ':'').$^X -e 1|);
+open(G, '|'.$^X -e 1|);
close(G);
EXPECT
Can't open bidirectional pipe at - line 3.
--- t/op/lex_assign.t_blead Mon Aug 1 22:52:28 2005
+++ t/op/lex_assign.t Mon Aug 1 22:52:34 2005
@@ -8,7 +8,7 @@
$| = 1;
umask 0;
$xref = \ ;
-$runme = ($^O eq 'VMS' ? 'MCR ' : '') . $^X;
+$runme = $^X;
@a = (1..5);
%h = (1..6);
$aref = [EMAIL PROTECTED];
--- t/op/runlevel.t_blead Mon Aug 1 23:01:00 2005
+++ t/op/runlevel.t Mon Aug 1 23:01:22 2005
@@ -34,7 +34,7 @@
print TEST $prog\n;
close TEST or die Could not close: $!;
my $results = $Is_VMS ?
- `MCR $^X -I[-.lib] $switch $tmpfile 21` :
+ `$^X -I[-.lib] $switch $tmpfile 21` :
$Is_MSWin32 ?
`.\\perl -I../lib $switch $tmpfile 21` :
$Is_NetWare ?
--- t/x2p/s2p.t_blead Mon Aug 1 23:09:15 2005
+++ t/x2p/s2p.t Mon Aug 1 23:09:20 2005
@@ -791,6 +791,8 @@
my $psed = File::Spec-catfile( File::Spec-curdir(), 'psed' );
if ($^O eq 'VMS') {
#
