| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code (which only runs if you have set PERLSHR_USE_GSMATCH in
the environment) has not been updated in a long time. It was
assuming that $] had only five digits after the decimal, whereas
it's had six for some time. And it assumed that the Perl5 version
could be represented in 4 bits, which was true up through 5.15
but isn't true anymore.
So get all the digits of the version number, and go wild and spend
5 bits on the value of $Config{PERL_VERSION}, which will get us
through 5.31. That only leaves three bits in which to encode all
the options that could break binary compatibility, whereas in fact
we need about thirty bits.
So clearly this only works in a situation where the configuration
can be standardized and/or different configurations are packaged
separately.
|
| |
|
|
|
|
| |
Previous descrip_mms.template carried separate rules to build perlintern.pod
and perlapi.pod, each of which caused autodoc.pl to run. autdoc.pl builds
both files when it runs, so this was duplicate work.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
fakethr.h and FAKE_THREADS were for a "green" threads implementation of
5005threads. 5005threads itself is long gone, and it's not clear that
-DFAKE_THREADS *ever* built correctly. Certainly it did not work for the
5.005 release, and it did not work at the time of the commits for the initial
checkin. The closest that it seems to have been to working is around commit
c6ee37c52f2ca9e5 (Dec 1997), where the headers no longer contained errors,
but perl.c failed to compile.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Happy 20th Anniversary, Charles.
|
| |
|
|
|
|
|
|
|
|
|
| |
The CRTL's fstat() sets errno to EVMSERR and vaxc$errno to RMS$_IOP
when called on a proccess-permanent file (i.e., stdin, stdout, or
stderr). That error generally means a rewind operation on a file
that cannot be rewound. It's odd that fstat is doing such a thing,
but we can at least protect ourselves from the effects of it by
saving errno and restoring it on a successful call.
This cures a couple of test failures and TODOs in t/io/errno.t.
|
| | |
|
| |
|
|
|
| |
And while we're there, set errno appropriately for the empty string
input case.
|
| | |
|
| |
|
|
|
|
|
| |
The macro used in vms/vms.c for errors from native calls deemed
too severe to handle was calling fprintf without checking return
values, which caused a huge pile of warnings when compiling with
/WARN=ENABLE=LEVEL5. So suppress those warnings with a void cast.
|
| | |
|
| |
|
|
|
|
| |
Since we now enable some features that are not the CRTL's defaults,
we should allow them to be explicitly disabled in the environment
if someone wants the old behavior.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature has been available for over a decade but is still not
the default for the CRTL. It seems time to make it the default
for Perl. It means that directory names can have dots in them,
and filenames can contain multiple dots as well as spaces and
generally characters from the top row of the keyboard while the
shift key is held down.
Filenames with native syntax must escape characters in the so-called
extended character set with a caret ("^"), but filenames in Unix
syntax must not have the escapes. Conversions between native and
Unix syntax will, respectively, add and remove these escapes.
Supporting Unicode in filenames depends on this feature but has
not yet been investigated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've been making our home-grown readdir implementation convert
all its results to Unix format since a096370a74e8. Since readdir
returns relative paths, the usual volume and directory syntax
differences that distinguish VMS and Unix paths don't really apply.
But what does apply is whether the escaping of extended characters
is passed through or removed, and converting to Unix syntax removes
those escapes. In order to enable extended filename syntax, though,
we're really going to need the escapes. For example, rmdir will
not be able to remove a directory foo.bar if it's referred to as
[.foo.bar] because a dot is the traditional directory delimiter.
The directory needs to be specified as [.foo^.bar] for rmdir to
delete it successfully.
So make readdir return filespecs in native format unless explicitly
requested to report all filenames in Unix format.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes filename components get pasted together in ways that put
a component with caret escapes proper to Extended Filename Syntax
(EFS) for native filespecs into a Unix-format filespec. An example
would be /a/b/foo^_bar, where the '^_' sequence indicates a space
in a native filespec but is technically invalid in a Unix
filespec.
But it doesn't really cost much more to remove the escapes since
we're copying the whole string anyway, so go ahead and do that.
This could theoretically cause trouble if we get Unix-format paths
that have literal carets in them, but that theoretical trouble is
currently less troubling than the practical trouble that crops up
various places in the test suite if we don't do this.
|
| |
|
|
|
|
|
|
|
| |
When converting VMS format file specification to Unix format, we
need to translate sequences escaped with a caret in the VMS format
name into an unescaped form in the resulting Unix name. We have
a function to do just that, but weren't using it in three of the
most important places that need it. Using the function gets us
handling more cases than the simple versions we had inline.
|
