[Top][All Lists]

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

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

From: h.becker
Subject: Re: vms argv[0] and exit status fixes.
Date: Fri, 07 Mar 2014 01:14:23 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130519 Icedove/17.0.5

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.

> 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.

> 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.

> 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

> 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.

>> 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 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

> 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.

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.

reply via email to

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