Re: vms argv[0] and exit status fixes.

[John E. Malmberg]

On 3/6/2014 6:14 PM, h.becker wrote:
> I'm still looking at this. I moved the code to places where I think they
> should go, but I'm not yet done. But I have some comments:
>
> On 03/06/2014 06:18 AM, John E. Malmberg wrote:
> > ...
> >
> > There is no way that I know of to know what foreign symbol was used to
> > invoke an image.  All we get is the image path in one of three formats
> > based on what the decc$ feature settings.
>
> For DCL it will be only one format.

Not true.  The decc$ features can be set by logical names, and a user 
may have set them for the various formats.

If a C program can be broken by an incorrect decc$ feature name, it 
should protect itself with a lib$initialize section.

I have a standard one that can be used for almost all programs that 
detects if the program is running under DCL or GNV Bash and sets the 
features as would normally be expected.

> > I think that a solution is to convert the original arvg[0] to VMS format
> > if needed and then use lib$set_symbol() to create a foreign command that
> > is visible to the child programs with the new argv[0].
> > ...
> > The side effect is that it leaves a local symbol make behind.  Not too bad.
>
> Hmm, silently making a symbol, maybe even silently overwriting an
> existing one? I disagree.

How about this, I append the process ID string to the symbol to make it 
unique, and then use an at_exit() call to delete it.

That way the makefile if the makefile goes to use a symbol like "make" 
by name instead of the macro, it will get what the user set "make" to be.

> > That source module is or can be a common source file for the latest
> > ports of GNU bash, grep, and sed.
>
> OK, but that's not applicable, here.

It simplifies my porting efforts, when I can just drop in modules as 
needed with out editing the original source.

> > I made setting the symbol a compile time option, since those other
> > programs do not need it set.
>
> I agree, but I would want to have these symbols definable in
> config.h-vms[.template]

This program wraps around the main() module, so either must be included
into main either implicitly, or with a /first_include feature.

I figured the macros should be set near the #include.

The first_include feature is not available on VAX/VMS.

> > If someone has defined /TMP to other than SYS$SCRATCH: then they will
> > probably be suprised if a GNU utility is not honoring it and still using
> > SYS$SCRATCH:
>
> For DCL, I don't think so.

What ever is done, it needs to be documented in the readme.vms and 
probably the gnu make manual as a VMS feature.  As clear

To have it different under GNV will require a global variable to use as 
a flag to be set if getenv("SHELL") returns a value, as I do think we 
want to call gentenv("SHELL") every place GNV needs alternative behavior.
> > > exit -> vms_exit:
> > >
> > > Looks good to me, except MAKE_FAILURE is mapped twice and MAKE_TROUBLE
> > > isn't mapped.
> >
> > A bug, easily fixed.
>
> It seems MAKE_TROUBLE is used with -q, so it is more an informational
> message. But I haven't yet checked whether MAKE_TROUBLE is used anywhere
> else.

If make trouble is informational, then the severity can be adjusted.

> > > If possible I would move the vms_exit function into a vms specific C
> > > source, either an existing one or a new one. I would move any other vms
> > > wrapper in such a module as well and reduce the to be included stuff to
> > > "usual" header file content. (OK, I know there is vmsjobs.c)
> >
> > If we move it out of a header file, it is no longer an in-lined static
> > function.
>
> Correct. But is in-lining necessary for a function which is called only
> once?

Probably not.

> > If die() is the only thing that calls exit, we can put it in the main.c
> > module.
> >
> > The other place for it would be in the config.h-vms.template file.
>
> I prefer to have all vms specific code in the existing vms sources,
> vmsfunctions.c may be the one for the new code.

I would prefer multiple modules, so that they can be re-used between 
other projects.  A vmsfunctions.c could #include these modules.

> Also, it seems a lot of code just to adjust/manipulate argv[0], I would
> like to keep it simple. Adding an mcr prefix is simple. I agree, that
> may not work for gnv and I didn't do much testing with it.

My concern is if a macro expands to two words instead of one, it could 
unexpectedly break something.

Regards,
-John