Re: vms:test variables

[h.becker]

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
code/work.

> 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
echo GNUMAKEFLAGS = $$GNUMAKEFLAGS
will become
write sys$output "GNUMAKEFLAGS = ",GNUMAKEFLAGS