| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default for populating %ENV on VMS is from logical names
first and the CRTL environ array second unless overridden by
setting PERL_ENV_TABLES. That's a reasonable default for DCL,
but not quite right when running under bash as exports under bash
might end up hidden behind logical names. So reverse the default
order when GNV$UNIX_SHELL is set.
Also stop mentioning that setenv() may not be present in the CRTL
since it is present for VMS versions 7.0 and later and those are
the only ones we support.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The standard does not indicate any errno values set when getenv()
simply doesn't find the requested value, which is a pretty common
occurrence. The VMS-specific implementation of getenv() has been
setting errno in this case, which means there is often an errno
value hanging around for later unsuspecting operations. It
particularly tends to bite people who don't read the documentation
to die() and/or don't understand how errno works (only valid after
a failed syscall).
So we now stop setting errno in this case, but leave it for a few
serious errors that should be extremely rare.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Back in 8dc9d3390b257b I consolidated two routines that were
almost identical -- except for their return values. The routine
I kept returns the length of the equivalence name after logical
name translation, but some uses of it were checking it to see if
it was a successful VMS condition value. Which means an odd length
(such as from "1") was successful but an even length (such as from
"ENABLE", the value recommended in the documentation) failed. So
fix those uses to check for a non-zero from simple_trnlnm.
For most features this only affected pre-7.3 systems, i.e., VMS
releases more than thirteen years old. However, it also affected
features such as PERL_VMS_POSIX_EXIT that we have made up on our
own and are not tracking a CRTL feature.
|
| |
|
| |
|
|
|
|
|
| |
C didn't notice this with standard warnings enabled, but C++ takes
vengeance, so cast appropriately.
|
|
|
|
|
|
| |
Without an explicit rule it gets build with CFLAGS rather than
CORECFLAGS, which could make it miss important things, such as
PERL_CORE being defined.
|
|
|
|
|
| |
This removes find2perl, s2p and a2p from core. They have all been
released to CPAN as separate distributions.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to d5e61aaf9d7051b136, where we stopped
escaping semicolons in tovmsspec when they appeared to be the
beginning of a version specification but always escaped them
otherwise.
It turns out there is yet another CRTL feature logical name
(DECC$FILENAME_UNIX_NO_VERSION) that tells us a Unix-format
specification is not allowed to have a version number, so in
that case, always escape the semicolon since it can't be the
start of a version specification.
Also, don't add the version number when fileifying directory
specs if this "no versions" feature is in effect.
|
|
|
|
|
|
|
|
|
|
|
| |
In theory, a Unix-format filespec can contain a semicolon and thus
need to be escaped when converted to a VMS-format filespec. But
a much more common use case is a filespec that has a version
number despite being in Unix format.
So detect a semicolon that delimits a version specification and
pass it through but escape other semicolons. This is apparently
what decc$to_vms does, so we're being consistent with the CRTL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was replaced by the standard tms struct in v7.0, released in
1995. Explicit support for pre-7.0 was removed in 32995a382d65b
for Perl 5.16, but I missed the tbuffer_t bit, which tripped up
Nicholas in 25983af42cdcf2dc, because he asked for:
struct tbuffer_t
which via macro expansion became:
struct struct tms
which failed to compile. So remove code that's unnecessarily
different on VMS, leaving only a tbuffer_t compatibility macro
with a more appropriate comment so it will hopefully be less
likely to get used in new code.
|
|
|
|
|
|
| |
av_tindex is a more clearly named synonym for av_len, available starting
in v5.18. This changes the core uses to it, including modules in /ext,
which are not dual-lifed.
|
| |
|
|
|
|
|
|
|
|
|
| |
In particular, a node specification containing only a single
directory (i.e., node::dev:[dir]) was not being handled properly.
This came up while reproducing the problem in [perl #121002] but
was not the cause of that problem as the OP's directory had
multiple subdirectories in it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported in [perl #121002], the homegrown opendir has been
failing when the directory specification contains a DECNet node
specification indicating the directory to be accessed is on a
remote node. The OP reports this worked with Perl 5.001 but not
5.8.6 or 5.18.2.
It appears that the culprit was the introduction of access
checking to Perl_opendir in 61bb59065bf1b12edab39b12, which would
first have been released in 5.004. Yes, it's been broken for 17
years.
The reason access checking broke remote access is that it's based
on SYS$CHECK_ACCESS, which apparently does not work on remotes,
though the only hint of that in its documentation is that the
status SS$_UNSUPPORTED, "Operations on remote object are not
supported" is listed as a possible return value. What it actually
returns, despite the documentation, is SS$_INVFILFOROP, "invalid
file specification for operation."
The fix is simple enough -- just skip the access check if the
directory name contains a node specification (which always ends
with "::"). All the access check is providing is a friendlier
error message in cases where we don't have access, so no harm is
done by skipping the check in cases where it can't work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The perl_setup.com command procedure initializes the root logical
name, the shareable image logical name pointing to the main Perl
dynamic library, and either command symbols or command table
entries that reference those logical names. It's always by
default hard-coded the prefix chosen at configuration time as the
basis for where Perl should be located.
The original rationale for that was that it gets run right before
installperl and sets things up correctly for installation. But
that optimizes for a single use case that is easily handled by
specifying the correct install location as a parameter and
pessimizes for every other use case, notably relocating an
installed Perl directory tree.
So make it infer the correct root from its own location and
specify the install location only at installation time. Among
other benefits, this allows the install location to be chosen
at installation time by overriding the default prefix like so:
MMK/MACRO=(PREFIX="DSA0:[homedir.MyPerl2.]") install
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Passing a path to int_tovmsspec that contained an "extended"
character as the first character when converting a Unix filespec
to VMS format skipped escaping that character, but only when the
path spec had no directory component. The character that didn't
get escaped could then be passed to a native service that choked
or incorrectly processed it. For example ' foo.txt' remained,
after translation, ' foo.txt', but parsing that as a native spec
would squeeze out the leading space.
So we now make sure we don't eat the first character of the
filename component while processing the directory component and
also handle escaping the very first character. In the example
of ' foo.txt', it now gets correctly translated to '^_foo.txt'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to e2d6c6fbf5bb. The use case I've seen is
that the translation of SYS$INPUT succeeds but the stat on the
resulting file/device fails, possibly due to object protections.
So we would be giving the child something it can't open.
Add error checking to the logic so in order to set up inheritance
of SYS$INPUT:
1.) The translation of SYS$INPUT must succeed.
2.) stat() on the resulting spec must succeed.
3.) The resulting spec must not be a directory.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation to LIB$SPAWN says that standard input will be
inherited from the parent if not specified, and we've been
depending on that. But it seems not to actually work that way
as a simple
$ perl -e "system('edit foo.tmp');"
was failing due to the input not being a terminal. So set up the
input explicitly using the same mechanism we've always used for
output and error.
Except when SYS$INPUT is a "directory," which probably means it's
a channel open on a volume that holds a command procedure.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing a logical name translation of a process-permanent file
(SYS$INPUT, SYS$OUTPUT, SYS$ERROR, or SYS$COMMAND), we need to
remove the special 0x001b prefix from the translation string
regardless of whether we are combining a search list into a
longer equivalence string or just doing a simple, index-free
lookup.
Since we now have two places needing the same logic, move that
logic into a static inline function.
|
| |
|
|
|
|
|
| |
Though the list of C files does not appear to actually be used in
the build.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a35dcc95dd24524931e I "improved" string safety in vms/vms.c by
converting to my_strlcpy and my_strlcat, but mangled the length
argument to my_strlcat when adding the name of the logical name
table specified in PERL_ENV_TABLES. This caused the command string
to be truncated, so a command that, for example, should have been:
$ Show Logical * /Table=LNM$JOB
...
actually became:
$ Show Logical * /Table=
%DCL-W-VALREQ, missing qualifier or keyword value - supply all required values
Plus it turns out the strings holding the names of the tables were
being stored in dynamic string descriptors and were not
NUL-terminated, but the strl* functions require NUL-terminated
arguments. So change those to static string descriptors and
allocate the exact amount of storage needed including room for a
NUL.
This was a regression in 5.16.0, first reported a couple of days
ago by Mark Daniel on comp.os.vms:
Date: Fri, 06 Sep 2013 12:56:01 +0930
From: Mark Daniel <mark.daniel [AT] wasd.vsm.com.au>
Newsgroups: comp.os.vms
Message-ID: <52294b4a$0$2875$c3e8da3$76491128@news.astraweb.com>
TODO: Figure out how and where to test this.
|
|
|
|
|
|
|
|
|
|
| |
Make the array interface 64-bit safe by using SSize_t instead of I32
for array indices.
This is based on a patch by Chip Salzenberg.
This completes what the previous commit began when it changed
av_extend.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding a first argument as a reference to the filename "perlmain.c" makes
ExtUtils::Miniperl::writemain() open and close the file for us. This is
safer than having the Makefile create the file using output redirection as
that can create an empty file if compilation aborts. This change means that
the file is only moved into place with the correct name if it has been
written completely without error. If an error happens the file is not
created, the make aborts, and any subsequent make will re-attempt to create
the file, instead of continuing with an incorrect file, hiding the real
cause of the problems.
|
|
|
|
|
|
|
|
|
|
|
| |
That commit moved VMS::Filespec from vms/ext to ext/, but it also
deleted the vmspipe.com dependency from the LIBPREREQ target in
vms/descrip_mms.template. (vmspipe.com has nothing to do with
VMS::Filespec.) Which meant vmspipe.com was not availabe for
building extensions or running tests, and -- worse yet -- would
not get installed. So every pipe creation would involve creating
a temporary version of this file using fallback code in vms/vms.c,
thus making the very pokey pipe implementation even more expensive.
|
|
|
|
|
|
|
|
|
| |
It does increase the lines of code slightly but it replaces a bunch of
platform specific special case code in the Makefiles for *nix, Win32 and VMS
with one unified implementation. And in Perl, rather than 3+ different
languages.
This feels like the right maintainability trade-off.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rules to remove C and object files from vms/ext were made redundant when
commit 26dd53a231877708 in Sep 2009 moved the XS extensions from there to
ext/
The wildcard rule to remove t/lib/vms*.t, which has been in
vms/descrip_mms.template since the file was added by commit 97abc6adffcd3efc
in June 1998 was effectively made redundant when it was duplicated by 4
specific rules for the 4 files it matched added by commit 493ba88a837f5a6b
in June 2001.
The rule to delete t/lib/vmsish.t was made redundant when vms/ext/vmsish.*
were moved to lib/ by commit 9f84c00564fd021b in Nov 2001.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We need to do whatever the configuration says we are doing via
$Config{dbgprefix} and/or $Config{usevmsdebug} for extension
building to work, so it makes sense for the top-level build to
also base what it is doing on the configuration choice rather
than on the special invocation of MMK with /MACRO=__DEBUG__=1.
So this patch makes the top-level build do what we've configured
to do and eliminates the instruction to use the macro.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
write_buildcustomize.pl now opens lib/buildcustomize.pl itself, instead of
writing to STDOUT and relying on the Makefile to set up redirection. This
means that an empty lib/buildcustomize.pl is not created if
write_buildcustomize.pl fails to compile (for whatever reason), and permits
write_buildcustomize.pl to delete (or attempt to delete) the output file if
it detects an error.
Hard code the output file name (lib/buildcustomize.pl), as it's the same on
all platforms, and @ARGV is already used to optionally pass a directory for
write_buildcustomize.pl to change to before running.
Experimentation suggests that various make utilities don't delete a file
created by redirection even if an error occurs. Hence this should be more
robust.
Add -f to the miniperl commandline when running write_buildcustomize.pl to
avoid reading in any existing lib/buildcustomize.pl. write_buildcustomize.pl
doesn't need the setup provided by lib/buildcustomize.pl, and running it
might cause errors which prevents writing out a correct version, making an
incomplete build harder to recover from.
|
|
|
|
|
|
|
|
|
|
|
| |
Now that lib/buildcustomize.pl is built at the same time as building
miniperl, it will always have added paths to Cwd into @INC. Hence there's no
longer a need for Makefile macros to do this.
On Win32 we can't eliminate $(ICWD) completely as it's also being used for some
invocations of the (real) perl binary. Only miniperl loads buildcustomize.pl
to set up @INC to include paths for the initial locations of modules such
as Cwd.
|
|
|
|
|
|
|
|
|
| |
Doing them together ensures that we always have lib/buildcustomize.pl
available. This simplifies things. The seemingly cranky ordering of having
miniperl notionally depend on lib/buildcustomize.pl, and the rule for
lib/buildcustomize.pl actually also building miniperl permits the rest of
the Makefile to depend on (the obvious) miniperl, not the obscure
lib/buildcustomize.pl
|