On Fri, 25 Apr 2008, David Berry wrote:
> 2008/4/25 Tim Jenness <[log in to unmask]>:
>> [copied to stardev due to bizarreness]
>>
>> On Fri, 25 Apr 2008, David Berry wrote:
>>
>>> On a related note, I've been at this job for 22 years now, and I have
>>> never noticed that you cannot include equals signs in values for
>>> LITERAL parameters unless you quote the whole string (and I'm talking
>>> about responding to a program prompt here, not supplying a value on
>>> the command line). Try:
>>>
>>> % settitle fred.sdf
>>> TITLE - New NDF title > black = white
>>> !! SUBPAR: Input line syntax error /black = white/
>>>
>>> You learn something new every day. This behaviour is caused by
>>> pcs/subpar/sup_hdsin.f. The history in the prologue makes it look like
>>> it did at one point treat LITERAL parameters literally, but was
>>> re-written in 1987 by JAB. Presumably, the behaviour changed then. But
>>> Alan seems later to have specifically changed things to allow "=" in
>>> _CHAR parameter values. Shame he didn't also do LITERAL parameters. I
>>> suppose it's too late to change this behaviour now since people have
>>> probably got quotes embedded in their scripts and things.
>>>
>>
>> Don't suppose the '=' has an actual purpose in the parameter system?
>
> None that I can think of (apart form the obvious one of splitting up
> "keyword=value" strings supplied on the command line). The sup_hdsin.f
> routine parses its input using LEX_CMDLINE, which has the specific
> purpose of parsing a command line. So whay a string supplied to a
> prompt is being parsed like a command line, I don't know.
>
>> Is
>> there a comment as to why '=' is special?
>
> No. The history is
>
> * 24-MAR-1993 (AJC):
> * Allow = in string in response to prompt for CHAR
>
>> Why don't STYLE parameters have the problem in KAPPA? Are they "CHAR"?
>
> STYLE parameters are obtained using GRP_GROUP which uses subpar
> directly, rather than calling PAR_GET0C.
>
>> I'll be impressed if fixing this breaks things. Most people have trouble
>> with quoting arguments on the command line at all. You're almost implying
>> that you'll need 3 sets of quotes on the command line if a comma is involved
>> :-)
>
> We could fix it, and wait to see if anyone shouts ....
Hold on, checking SUN/115 I see:
\item LITERAL -- formerly used to specify that the parameter is of type
\_CHAR and to force the parameter system to accept unquoted character
strings as character values rather than HDS object names.
This is now the standard behaviour for parameters of type \_CHAR so
datatype LITERAL is no longer required.
A quick test program shows the same behaviour for _CHAR and LITERAL, that
is both require quotes (remembered Alan saying these types had effectively
merged at some time), so fixing one fixes both and that comment by Alan is
clearly out of date.
|