| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This simplifies the VMS Makefile. It would have simplified the VMS Makefile
further if it had had the correct rules to delete [.lib.VMS]Filespec.pm
which are now no longer needed. (The generated ext/VMS-Filespec/DESCRIP.MMS
will now take care of this.)
|
|
|
|
|
|
| |
The mode of this file has rattled back and forth between +x and -x since it
was first added. It makes no difference which it is, so remove -x and hence
1 special case.
|
|
|
|
|
|
|
|
|
|
|
| |
c1abd561a0a322 avoided the double escaping of dots in filenames,
but failed to copy the dot itself in cases where it was already
escaped. Plus, when not using extended file specifications and
thus converting the dot to an underscore, we need to make sure
the underscore is not escaped.
And add a test that covers most of these scenarios. Probably
more tests are needed.
|
|
|
|
|
|
|
|
|
|
| |
For some reason the omnibus patch (360732b5267d5dfe) that brought
Extended Filename Syntax support to the VMS port considered three
dots part of the filename portion rather than part of the
directory portion when converting a Unix-format path to VMS format.
There's no reason this should be different with EFS, so make it
the same as without EFS, which gets two TODO tests passing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In df2786654 and 8a5aa89570, the traditional behavior of adding
the .DIR;1 onto a fileified directory spec was removed when
operating under Extended Filename Syntax. Various scary comments
were added about its being a bug to add a type and version onto
a Unix-style path, but actually the CRTL appears to be perfectly
happy with, for example:
stat('/foo/bar/baz.dir;1');
and without the extension, the home-grown rmdir() fails in the
case of a directory with no preceding path information. E.g.,
rmdir('foo');
was failing because there was no internal translation to foo.dir
before passing it to SYS$ERASE.
Moreover, even if there were something wrong with adding .DIR;1,
it has nothing to do with EFS.
|
|
|
|
|
| |
Two tests that actually pass under Extended Filename Syntax and
two that will now pass if we give them the correct expectations.
|
|
|
|
|
|
|
|
|
|
|
| |
1fe570cc5e24eecfb07059e53e95fa864bb44142 declared directory
components containing '...' as either 'not translatable' or created
the expectation that each dot should be individually escaped when
translating between Unix and VMS directory specs. That doesn't
really make sense since in both formats it means any number of
intervening directories, plus there was already code of long
standing that handles it. So get the tests in this regard back
in line with reality.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Way back in 08c7cbbb0fc466967038dcb56ca4f1b828b96269, we started
eliminating ../ components when converting paths from Unix syntax
to VMS syntax. No corresponding change was made when converting
in the opposite direction, so this was inconsistent. We should
get a valid path either way, but doing more interpretation than
necessary seems uncalled for, so this patch restores the previous
behavior.
This also paves the way to eliminate some inconsistencies between
what we do when Extended Filename Syntax (EFS) is in effect and
when it's not.
|
|
|
|
|
|
| |
When Extended Filename Syntax is enabled, several tests were
expecting not to pass, but they do, so we should say so. Also,
reinstate a test removed in 1fe570cc5e24eecfb07059e53e95fa864bb44142.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When porting/makerel runs, all files copied into the directory for the
tarball have the executable bit stripped and then only a specific set of
files have the executable bit restored.
There are many files in the repo that have the executable bit set in the
repo that will be stripped. So that the state of files in the repo is
as close as possible to the state of files in the release tarball, the
executable bit has been stripped from such files.
In one recent case, a file added from a dual-life module needed the
executable bit set. Because it had the bit in the repo but was
not listed in makerel to get an executable bit, tests using it
passed in the repo and failed in the tarball.
This commit refactors the list into a new file, Porting/exec-bit.txt
and add tests to detect a mismatch between files listed there
and actual executable bits in the repo.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have been getting:
$ perl -e "print VMS::Filespec::unixify('foo:<bar>');"
/foo/<bar/
but should be (and now are) getting:
$ perl -e "print VMS::Filespec::unixify('foo:<bar>');"
/foo/bar/
|
|
|
|
|
| |
We should be able to depend on SYS$SCRATCH being a non-rooted
logical name.
|
|
|
|
| |
This reduces the number of places with special-casing logic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces pathify_dirspec in vms.c with a new version that better
handles the extended character set.
The [.vms.ext]filespec.t has been adjusted for to support both the
default mode and the extended file spec mode.
This fixes an inconsistency where now vmsify and vmspath will return the
same result for similar input.
Message-ID: <49737F12.6010803@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
since 5.8.8, ready for merging into maint-5.8 prior to 5.8.9.
(Many (all?) of these should really have been changed prior to
5.10.0, but better late than never.)
Also modify cmpVERSION.pl to skip uninstalled test modules whose
VERSIONs don't really matter.
p4raw-id: //depot/perl@34365
|
|
|
| |
p4raw-id: //depot/perl@32791
|
|
|
|
|
|
| |
system specific directories. I think I've chainsawed all of them now,
but I can't guarantee that it compiles anywhere from win32.
p4raw-id: //depot/perl@32713
|
|
|
| |
p4raw-id: //depot/perl@32601
|
|
|
| |
p4raw-id: //depot/perl@32594
|
|
|
|
|
|
|
|
|
| |
From: "John E. Malmberg" <wb8tyw@qsl.net>
Message-id: <473FF49A.5000302@qsl.net>
[.vms...] parts with revisions to compile on older systems and some
POD clean-up.
p4raw-id: //depot/perl@32474
|
|
|
| |
p4raw-id: //depot/perl@31384
|
|
|
|
|
|
| |
precedence mistakes, but for now give the same symbol mangling
results as before.
p4raw-id: //depot/perl@31236
|
|
|
|
|
| |
filenames from VMS to UNIX syntax.
p4raw-id: //depot/perl@30602
|
|
|
|
|
|
| |
because Carp now in some cases depends on things that may not
be available from miniperl or before extensions are built.
p4raw-id: //depot/perl@30177
|
|
|
|
|
|
|
| |
PerlIO world via Unix I/O. If you start from stdio, a Unix I/O counter
will get decremented on close even though it was never incremented (and
may not even exist). Exposed by #29065.
p4raw-id: //depot/perl@29144
|
|
|
| |
p4raw-id: //depot/perl@28977
|
|
|
|
|
|
|
|
| |
Keep NEWSV() itself for backwards-compatibility outside of the core,
but don't advertise it any more.
(cf. change #25101).
p4raw-link: @25101 on //depot/perl: a02a5408b2f199007c4dcb74559cc79066307ada
p4raw-id: //depot/perl@26901
|
|
|
| |
p4raw-id: //depot/perl@26869
|
|
|
|
|
|
| |
From: "John E. Malmberg" <wb8tyw@qsl.net>
Message-ID: <42FAC54B.2050207@qsl.net>
p4raw-id: //depot/perl@25284
|
|
|
|
|
|
| |
From: "Craig A. Berry" <craigberry@mac.com>
Message-ID: <415D9F5B.5040306@mac.com>
p4raw-id: //depot/perl@23346
|
|
|
|
|
| |
Message-Id: <12FBA07F-E975-11D7-BDD7-003065F6D85A@mathforum.org>
p4raw-id: //depot/perl@21270
|
|
|
| |
p4raw-id: //depot/perl@20688
|
|
|
|
|
| |
Message-Id: <A3E1AAA0-BC81-11D7-B0BB-003065F6D85A@mathforum.org>
p4raw-id: //depot/perl@20197
|
|
|
|
|
|
| |
From: "Craig A. Berry" <craigberry@mac.com>
Message-ID: <3EAAF1B3.7020708@mac.com>
p4raw-id: //depot/perl@19349
|
|
|
|
|
|
| |
From: "Craig A. Berry" <craigberry@mac.com>
Message-ID: <3D88F6AE.3020708@mac.com>
p4raw-id: //depot/perl@17913
|
|
|
|
|
|
| |
From: "Craig A. Berry" <craigberry@mac.com>
Message-Id: <a05111b05b9535cbf2914@[172.16.52.1]>
p4raw-id: //depot/perl@17483
|
|
|
|
|
|
| |
From: "Craig A. Berry" <craigberry@mac.com>
Message-Id: <5.1.0.14.2.20020227152131.01ade728@exchi01>
p4raw-id: //depot/perl@14902
|
|
|
|
|
| |
Message-Id: <a05101000b8358a58eb28@[172.16.52.1]>
p4raw-id: //depot/perl@13498
|
|
|
|
|
| |
Message-Id: <5.1.0.14.2.20011205160043.02160e90@exchi01>
p4raw-id: //depot/perl@13481
|
|
|
|
|
|
| |
(There are some straddlers, but they will be fixed in the
upcoming releases of the modules.)
p4raw-id: //depot/perl@13034
|
|
|
|
|
| |
Message-ID: <20011112205034.H2888@blackrider>
p4raw-id: //depot/perl@12971
|
|
|
|
|
| |
Message-Id: <011112123409.27041@DUPHY4.Physics.Drexel.Edu>
p4raw-id: //depot/perl@12958
|
|
|
|
|
| |
Message-Id: <20011109014414.N5587@blackrider>
p4raw-id: //depot/perl@12918
|
|
|
|
|
| |
Message-Id: <011019174427.d749b@DUPHY4.Physics.Drexel.Edu>
p4raw-id: //depot/perl@12513
|
|
|
|
|
|
|
|
|
|
|
| |
TODO 1: double check that pre-5.6.1 CPAN.pm:s
don't try to download 5.8.0 because of the
version numbers. Mainly this means using _00
in the core version numbers.
TODO 2: the "use 5.005_64" in many modules
needs to be changed to, say, "use 5.6.1".
p4raw-id: //depot/perl@12040
|
|
|
|
|
| |
Message-ID: <Pine.OSF.4.10.10106221903270.24012-100000@aspara.forte.com>
p4raw-id: //depot/perl@10850
|
|
|
|
|
| |
Message-Id: <a05100e0ab734816701a5@[172.16.52.1]>
p4raw-id: //depot/perl@10218
|