Shell variables in menus?

[Brian K. White]

On 6/10/20 2:35 PM, Jay R. Ashworth via Filepro-list wrote:
> Do I remember that the menu runner spawns a new shell for each line and
> even exporting a set variable doesn't help?
>
> I need to do something like this:
>
> DATESTAMP="`date '+%Y%m%d_%H%M%S'`"
> export DATESTAMP
>
> And then pick up $DATESTAMP inside my prc tables with a GETENV()
>
> Right now it's coming back blank, and I don't think that's fixable.
>
> Is there a go-to solution for doing this kind of tagging at the scope of
> a menu script?

We do that all the time. There's definitely nothing too weird about the 
way F5 menu scripts are run.
Try another variable with a name that you know for sure isn't, can't be, 
being overwritten or unset,
and double-check a few things in the prc:
The getenv syntax: x = getenv("MYVAR")
The declared edit type of "x"  (value doesn't pass the edit?)
Whatever the test or comparison being used to check the value now, 
before that, just throw it up in an errorbox, preserving spaces, just to 
see for sure what's coming in.
errorbox "MYVAR=\"" & getenv("MYVAR") & "\""
errorbox "x=\"" & x & "\""

 From there you should see enough to know what's wrong and what to do 
next. Like wrapping the returned result in ""{x{"" or whatever.
You could even put in a system "sh" and just poke around in that 
environment manually and really see what's up.

Presumably you aren't running the clerk/report command with sudo or 
something which intentionally throws away the parent environment unless 
you give specific commandline options not to.