[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
config.h-vms[.template]
> 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.
>> 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 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?
> 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.
- vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/05
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/05
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/06
- Re: vms argv[0] and exit status fixes.,
h.becker <=
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/07
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/08
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/08
- VMS exit status fixes., John E. Malmberg, 2014/03/08
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/10
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/10
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/11
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/24
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/25
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/25