[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vms:test variables

From: h.becker
Subject: Re: vms:test variables
Date: Tue, 15 Apr 2014 17:46:46 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130519 Icedove/17.0.5

On 04/15/2014 03:06 PM, John E. Malmberg wrote:
> The fix there is on VMS to replace "echo > $@" with:
>  'open/write xxx $@ ; write xxx "" ; close xxx'

Yes, that should do the trick as other possible fixes can do the same.

> Perl choosing logical names as the default for implementing %ENV has
> turned out to be a major bug.  It is causing a lot of problems with
> porting programs and with the Perl self tests and also the perl
> makemaker, along with issues with the make test harness.

Can of worms? I didn't want or intend to open it, I just wanted to
describe what I observed. If GNU make for VMS uses local symbols for
exporting make variables it should work.

> If the recursive make is exec(), then there is a variant that allows an
> environment array to be passed.  This is the way that Bash passes
> exported variables to children.

I thought of that: there is more than just exec and it looks like a
major rewrite of the VMS version for child_execute_job.

> Yes a general export routine that saves the old value/state of a local
> DCL symbol on something like a linked list, creates a new local
> variable, and an atexit() routine that restores everything off of the list.

Looks like less code than a rewrite but is still a significant piece of

> But we also need to get symbol substitution working in the spawned DCL
> command.  Either by translating the makefile to use one of the VMS
> substitutions or by having the wrapper to lib$spawn do a shell emulation
> for such variables.

Which symbol substitution? The forced symbol substitution isn't done,
but the automatic ones are. With a changed makefile it will work. It's
the old trick
will become

reply via email to

[Prev in Thread] Current Thread [Next in Thread]