[Top][All Lists]

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

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

From: John E. Malmberg
Subject: Re: vms argv[0] and exit status fixes.
Date: Fri, 07 Mar 2014 07:24:01 -0600
User-agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

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

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

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

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

Correct. But is in-lining necessary for a function which is called only

Probably not.

If die() is the only thing that calls exit, we can put it in the main.c

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.


reply via email to

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