At 3:15 PM -0400 8/26/06, John E. Malmberg wrote:
>Craig A. Berry wrote:
>>In [.vms]vms.c, do_tounixspec(), we now convert sys$scratch to tmp
>>using the code below. This breaks things that convert to unix specs
>>for convenience and then convert back to VMS specs. Such as:
>>
>>$ perldoc -f opendir
>>Error in tempfile() using tmp:XXXXXXXXXX: Could not create temp file
>>tmp:x8rVYNDDzE: no such device or address at /perl_root/lib/Pod/Perldoc.
>>pm line 1507
>>%SYSTEM-F-ABORT, abort
>>
>>There is no "tmp:" device so you can't create a temporary file there.
>>So, I'm curious, since /sys$scratch is just as valid a unix fiile
>>spec as /tmp, why replace it?
>
>Good question.
>
>Under normal conditions CRTL will internally translate /tmp to SYS$SCRATCH: if
>the logical name "TMP:" does not exist.
>
>Since Perl sometimes uses the CRTL translations, and sometimes uses it's own,
>the UNIX to VMS translation needs to also do this, or we end up with parts of
>Perl translating UNIX file specifications to VMS differently.
>
>So /tmp/XXXXXXXX should work.
>
>But the CRTL does not do the reverse translation, which will break tests that
>assume that vmsify() will reverse a unixify().
Well, maybe Perl should do the reverse translation, turning /tmp into
sys$scratch: when no tmp logical exists.
>
>Anything that is converting a VMS format specification to a UNIX specification
>and then reversing it, is going to be broken for a number of VMS file
>specifications. One of the things that I am working on is removing all those
>double translation cases from the core modules, and updating the documentation
>for vmsify and unixify as to why.
>
>I am also trying to make sure that most of the common cases of
>"vmsify(unixify($foo)) == $foo" and "unixify(vmsify($foo)) == $foo" work,
>because the incorrect assumption that this can be done is so prevalent. These
>problems especially show up when the EFS character set is enabled.
>
>It appears here that something in Perldoc translated a VMS specification to
>UNIX, and then tried to treat portions of the UNIX specification as VMS format
>instead of keeping the file specification in UNIX format. That will only work
>with a subset of UNIX file specifications.
>
>Most likely the vms specific code that is causing this problem could/should
>simply be removed.
Well, here's the culprit:
$ perl -"MFile::Spec" -e "print File::Spec->eliminate_macros('sys$scratch:');"
/tmp/
Ditto with the MakeMaker version, which is now supposed to be the
authoritative version of eliminate_macros:
$ perl -"MExtUtils::MakeMaker" -e "print MM->eliminate_macros('sys$scratch:');"
/tmp/
Lots of things will break in MakeMaker if we simply remove
eliminate_macros. Whether it still needs to be called from catdir
and catpath in File::Spec is worth investigating. On the surface,
there should be no general reason to expand Makefile macros when not
generating a Makefile, but there may be other normalization features
of eliminate_macros that we've come to depend on. And even more
likely, there may be cases where MakeMaker calls catdir and catfile
and assumes that macros have been expanded.
>
>As of VMS 8.3, /tmp could be:
>
>"^UP^/tmp"
>tmp:
>sys$scratch:
>sys$posix_root:[tmp]
>
>All depending on how the C feature logicals, the POSIX root, or the logical
>names tmp or sys$posix_root are defined.
>
>Consider also the cases are that "./foo" is sometimes "[]foo.*" where * is
>based on the context of it being used by a VMS utility and other times it is
>simply "[]foo." where sometimes the trailing "." is significant.
>
>And "[]foo." needs to be translated to "./foo". "./foo." translates to
>"[]foo^..".
We clearly need lots and lots of test cases.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
