| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
When encountering a question mark in a filespec being converted
from Unix to VMS format, we were inadvertently adding an escaped
space because of a missing break in a switch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VMS::Filespec::unixify has been truncating its return value and
returning early when the input begins with [] meaning the current
directory. If there was nothing else, we've been getting the right
answer:
[] --> ./
but if there was a file portion of the name it's been getting
omitted:
[]foo.txt --> ./
which is now fixed. Looks like it's been broken since inception
in 5.002, though only with the specific [] case and not if there
was an explicit device or directory name.
|
| |
|
|
|
| |
Basically I missed a spot in 812e68ff314e, so the escaped space
in [foo^_bar], for example, was not translated correctly.
|
| |
|
|
|
|
|
|
|
|
|
| |
For some reason extended characters were only being escaped in
the final component of the path, but not in the directory portion,
the one exception being dots. We need to give the entire path
the same treatment. There is probably considerable opportunity
for further consolidation and refactoring in what we escape, but
at least now ../foo bar/ correctly becomes [-.foo^_^_bar].
The reverse case has similar problems and is a TODO.
|
| |
|
|
|
|
|
|
|
|
|
| |
When translating a filespec starting with an extended character,
say C<+foo>, from Unix to VMS format, we were inadvertently
skipping over the first character and thus not translating it to
C<^+foo> with the caret escape prepended to the plus sign as we
should have been.
This fixes a fairly new test failure in ExtUtils::Manifest where
a filename starts with a single quote.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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'.
|
| |
|
|
|
|
|
|
| |
Moving it caused it to fail because it expected test.pl to exist
in the directory it's being run from, but that isn't the case
anymore. We can now just depend on the test infrastructure to
control @INC and don't need any special handling of library
directories.
|
|
|
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.)
|
