On Fri, 25 Apr 2008, David Berry wrote:

> 2008/4/25 Peter W. Draper <[log in to unmask]>:
>>
>> 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.
>
> If it's a genuine bug, then we could claim to be justified in fixing
> it even if this breaks people's scripts (maybe)...

I'd vote for the change. Assuming as you say this only effects the 
response to a prompt.