From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 24-MAY-1992 12:53:16.03
To:	info-vax@kl.sri.com
CC:	
Subj:	Re: execvp() (VAX C) question

In article <1992May21.110318@mccall.com>, tp@mccall.com (Terry Poot) writes...
> I'm porting Ghostview to VMS, and I'm having one rather nasty problem.
> It uses vfork() and execvp() to spawn ghostscript.  This works fine if
> the ghostscript executable is in the current default directory, but I
> can't come up with any combination that makes it work when ghostscript
> is anywhere else.
>
> $ show logical vaxc$path
>    "VAXC$PATH" = "LSRC:[GS]" (LNM$JOB_81226690)
> $ gv gs_lib:golfer.ps
> %DCL-W-ACTIMAGE, error activating image VAXC$PATH:GS.EXE
> -CLI-E-IMAGEFNF, image file not found MIS2$DKA100:[LOCAL.][GHOSTVIEW]GS.EXE;
>
> It also doesn't work when vaxc$path is defined /sys/exec.  Currently, the
> filename argument to execvp() is "gs.exe".  It seems that VAXC$PATH is
> prepended to that argument, so that if I put a device and directory on
> it, it gives me a syntax error.
>
> Does anyone know how this stupid thing works? (Or does it?)

     The C startup code does the equivalent of
       $ define/process/user_mode vaxc$path 'getenv("PATH")'
so your job and system definitions will never be seen.  Normally you
should just use
       $ define path lsrc:[gs]
before running the program, but unfortunately getenv() has a bug
dealing with "PATH" when it doesn't have the default value, so this won't
work right.  (You might be able to work-around this bug by inserting a
binary NUL into the translation to terminate it; I haven't tried that.)

     So, your next best bet would be to change the program to use
sys$crelnm() to override the user-mode definition of VAXC$PATH with
the value you want.  Once you do that, you'll run into another problem...
When execvp() concatenates "VAXC$PATH:" with the argument that you pass
it, it does not properly NUL terminate the resulting string.  So the
value it passes on to execve() might have random junk at the end.
(In your case it didn't, or you wouldn't have received a valid filename
in the error messages you got, but you can't rely on that. :-(

     The simplest fix may be to use a command procedure which changes
the default to your target directory, executes the program, and then
resets back to wherever the user started from...  Or change the program
to construct the full filename itself and use execv() instead of execvp().

		Pat Rankin, rankin@eql.caltech.edu