[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: |
Wed, 05 Mar 2014 22:30:38 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130519 Icedove/17.0.5 |
I'm still looking at this, so I may change my mind or suggest to change
the code :-)
The main wrapper:
There were/are problems with the program name, however I'm not sure
whether the wrapper solves them. For DCL the wrapper, as before,
requires a foreign command pointing to the executable (or the logical
DCL$PATH pointing to the directory with the matching executable).
Consider
$ type *.mf
USR_ODS5:[BECKER_H.make]MAKE_COMMAND.mf;1
all:
@ $(ECHO) $(MAKE_COMMAND)
x:
$(MAKE_COMMAND) -f x.mf
USR_ODS5:[BECKER_H.make]x.mf;1
all:
@ $(ECHO) here we are
$
If you have
$ make := $USR_ODS5:[BECKER_H.make.make]make.exe
$ make -f MAKE_COMMAND.mf
make
$ make -f MAKE_COMMAND.mf x
make -f x.mf
here we are
$
but when you want to use a different symbol:
$ del/symb make
$ gmake := $USR_ODS5:[BECKER_H.make.make]make.exe
$ gmake -f MAKE_COMMAND.mf
make
$ gmake -f MAKE_COMMAND.mf x
make -f x.mf
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\MAKE\
$
I already made some changes for this, but I'm not yet convinced - it's
not really nice and there may be other side effects:
$ mymake:=$EISNER$DRA3:[DECUSERVE_USER.BECKER_H.USREXE]make
$ mymake -f MAKE_COMMAND.mf
mcr eisner$dra3:[decuserve_user.becker_h.usrexe]make.exe;2
$ mymake -f MAKE_COMMAND.mf x
mcr eisner$dra3:[decuserve_user.becker_h.usrexe]make.exe;2 -f x.mf
here we are
$
My change is more or less prefixing the default argv[0] with "mcr ".
SYS$SCRATCH:
I know that the VMS CRTL does some special handling for /tmp. As far as
I know, this is translated to SYS$SCRATCH:. So there seems to be no need
to replace sys$scratch with /tmp. But tmp (or TMP?) may be a logical
name pointing to a different directory and then that directory is used
as scratch directory. Whether that is a good thing or just confusing, is
another question. SYS$SCRATCH seems more obvious to me.
exit -> vms_exit:
Looks good to me, except MAKE_FAILURE is mapped twice and MAKE_TROUBLE
isn't mapped.
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)
On 03/05/2014 07:17 AM, John E. Malmberg wrote:
> * main.c, vms_main_wrapper.c (main): This fixes the VMS arvg[0] to be
> the normalized program name expected by users and test scripts. This
> handles the three possible syntax's that the argv[0] can be set to from
> DCL, and handled removing a facility prefix.
>
> When make is exec() from a C program, the argv[0] set by the exec() is
> also preserved as expected.
>
> The older VMS specific code that did not handle all these cases has been
> removed.
>
> Unneeded VMS specific code for tempfile processing removed. The VMS
> CRTL maps /tmp to SYS$SCRATCH: if TMP: does not exist.
>
> * makeint.h: Properly encode the Unix status as a VMS status code while
> setting the VMS severity and message inhibit bits. This allows programs
> written in C to see the documented and expected exit code, and sets the
> severity level for native VMS programs to use.
>
> This fix also inhibits the incorrect display of additional error
> messages after the program has exited.
>
> Regards,
> -John
>
>
> _______________________________________________
> Bug-make mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-make
>
- vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/05
- Re: vms argv[0] and exit status fixes.,
h.becker <=
- Re: vms argv[0] and exit status fixes., John E. Malmberg, 2014/03/06
- Re: vms argv[0] and exit status fixes., h.becker, 2014/03/06
- 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