Shell variables in menus?

[Jay R. Ashworth]

----- Original Message -----
> From: "Brian K. White via Filepro-list" <filepro-list at lists.celestial.com>

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

I tried picking up PATH in the debugger with e[valuate] and it comes back
fine.  Other system variables too.  It's just the one I set out in the 
menu script that I can't read.

> and double-check a few things in the prc:
> The getenv syntax: x = getenv("MYVAR")

Yup; I quoted it inside the parens.

> The declared edit type of "x"  (value doesn't pass the edit?)

(25,*)

> Whatever the test or comparison being used to check the value now,

I half-stepped through it in the debugger, and the variable (bt(25,8))
comes back empty.

> 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 & "\""
 
I *suspect* that running the debugger told me what I needed to know there,
but I'll try that anyway.

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

Hmmm.

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

Nope; just /appl/fp/dreport stgordrhe -f post yada yada yada

Odd.

Did drunmenu *used* to start a new child shell for each line it executed?
I'm sure I gotta remember that for *some* reason...

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates       http://www.bcp38.info          2000 Land Rover DII
St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647 1274