| Newsgroups |
gmane.comp.lang.perl.ports.vms |
| Message-ID |
<[email protected]> |
Jeremy,
On 15.07.2014 03:24, Jeremy Begg wrote:
> Hi John,
>
>> we came across this curious behaviour. Here enclosed please find a
>> reproducer.
>
> I see the same behaviour -- and also on Perl 5.10.0, so it's not new.
> Looks like inappropriate propagation of the last VMS error code.
>
I have just joined this distribution list, so what do you reckon are the
chances that this can be and will be resolved in the near
future?Obviously for a customer script we have to suppress this
misleading output, by other means.
>> PS. Why can't a PRODUCT INSTALL of PERL leave an older installation
>> alone (ie. do not start deleting files in the directory tree), or at
>> least offer an OPTION to leave the old installation as is?
>
> I'm not sure, but I suspect it's a required by-product of the PCSI
> installation process. And somewhat annoying, too!
>
> Using a PCSI kit also has problems if you want to install Perl onto a
> cluster-common disk, which is not the boot disk, because you end up with
> PRODUCT SHOW PRODUCT listing the kit on one machine but not on the
> other(s).
>
> The kit itself is just a complete directory tree so perhaps a PRODUCT
> EXTRACT command would do the trick instead?
>
Of course that is one approach, but seeing that someone has gone to all
the trouble of 'packetizing' perl it is a shame.
Surely in the 'open source' space one is never sure whether one's open
source based application is going to work with a new version of, in this
case perl, especially if one has compiled additional modules. So it
would make sense, to let you switch environments, from old to new and
back again. The way the PCSI works for perl at the moment, has become a
nugatory activity.
Kind regards
John