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