develooper Front page | perl.vmsperl | Postings from June 2002

Re: [PATCH: perl@16826] small updates to DCL portions of perl kit

Thread Previous | Thread Next
From:
PPrymmer
Date:
June 3, 2002 06:12
Subject:
Re: [PATCH: perl@16826] small updates to DCL portions of perl kit
Message ID:
OFF11E4987.F23AA382-ON85256BCD.0046D117@55.25.11

Brian Tillman wrote:
!>I don't know that it's incorrect, though it could be done more simply
like
!>
!>$ create 'file_2_find'
!>$ set file/attribute=(RFM:STMLF,RAT:CR) 'file_2_find'
!>$ open/append config 'file_2_find'
!
!/ATTRIBUTE on SET FILE didn't exist prior to V6.0.  Perhaps that's not a
!concern.

I am sorry for having set forth such a terse
justification for the seemingly elaborate
CREATE/FDL construct that I recently patched
into perl.  Here is a bit more detailed
description: 1) vile 9.2 was shown to me to
truncate the VFC bytes in a perl_setup.com
written by an older configure.com, and indeed
it omitted the leading "$" character that is
needed for a properly constructed DCL procedure.
While this should be considered a bug in vile,
the DCL "@" command to execute perl_setup.com
would not balk an executing either an RFM .eqs. "VAR"
or an RFM .eqs. "STMLF" perl_setup.com.
2) certain other bits of software, among them
the Perforce source code management system, and
NFS clients such as those found on Solaris 2.8
are happier with RFM .eqs. "STMLF".  In particular
the VMS perforce client "sync" command will pull out
a STMLF file from a Perforce depot.  Adding a
VFC or even a VAR RFM file to Perforce will
autoconvert it to a Perforce binary file type that
is not considered text hence is not considered
amenable to perforce commands such as diff, diff2,
or describe with the long output option.
Here again this could be considered a bug
in software that is not VMS native, but since
"@" can accept STMLF it seemed preferable
to have configure.com create perl_setup.com
with the STMLF record format.

Alas such a long winded explanation did not
lend itself to a quick patch submission on
p5p.

That said I am not opposed to switching to
VAR if you or anyone else can come forth with
an inconvenience scenario that clearly
demonstrates that it would be preferable to
STMLF (fear not as I am familiar with the
more succinct $CREATE $OPEN/APPEND idiom,
the more verbose CREATE/FDL construct is
actually used further up in the creation
of config.h from config.local).
Since I need to track changes to a
perl_setup.com using Perforce I would need to
use STMLF, but I can easily run a CONVERT/FDL
over a VAR version of the file before checking
it into my SCM system.  Would that be your
preference?  If so why?  Thanks.

Peter Prymmer



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About