Parsing bug with DEFINE AXIS
Closed this issue · 1 comments
This was reported as a Ferret issue, NOAA-PMEL/Ferret#1998 and the user closed it. However it is a bug.
A simplified version:
yes? let ts = "06-JAN-2016"
yes? let te = "12-NOV-2016"
yes? define axis/T="`ts`":"`te`":2/T0="`ts`"/units=hours taxis
**ERROR: invalid command: delta values may only modify variable names
define axis/T="06-JAN-2016":"12-NOV-2016":2/T0="`ts`"/units=hours taxis
Most often we have recommended people do this kind of thing using symbols, so this may be a long-standing bug that hasn't been reported before. That would go like this:
yes? define symbol ts = 06-JAN-2016
yes? define symbol te = 12-NOV-2016
yes? define axis/T="($ts)":"($te)":2/T0="($ts)"/units=hours taxis
!-> define axis/T="06-JAN-2016":"12-NOV-2016":2/T0="06-JAN-2016"/units=hours taxis
yes? show axis taxis
name axis # pts start end
TAXIS TIME 3733 r 06-JAN-2016 00:00 12-NOV-2016 00:00
T0 = 06-JAN-2016
Axis span (to cell edges) = 7466
However what was done in that original report should work fine.
This is fixed in fer/gnl/eval_expr.F, and a new benchmark test is added.
The grave-accent syntax to evaluate a variable involves looking at the context of the expression. Here it was looking at parts of the command that are not involved in the expression ts, and treating the LO:HI:DELTA from the command as if it applied to the string variable ts. This information needs to be ignored for evaluating the variable.