8:10 a.m.
Hi,
simple code:
<hansl>
set verbose off
nulldata 50
string desc = "This is something about my foo series"
series foo1 = normal()
series foo2 = normal()
series foo3 = normal()
setinfo foo1 --description=desc
setinfo foo2 --description="This is something about my foo series"
setinfo foo3 --description=@desc
</hansl>
So, why:
1. the first one works, but result is unexpected?
2. the second one works perfect?
3. the third doesn't work at all?.
Marcin
8:53 a.m.
Hi Marcin,
Am 21.06.2018 um 10:10 schrieb Marcin Błażejowski:
Hi,
simple code:
<hansl>
set verbose off
nulldata 50
string desc = "This is something about my foo series"
setinfo foo1 --description=desc
I am with you this should only work for "--description="desc" for
consistency reasons.
setinfo foo3 --description=@desc
This one works with "@desc" -- which is the standard way I think.
Best,
Artur
10:33 a.m.
Am 21.06.2018 um 10:53 schrieb Artur Tarassow:
Hi Marcin,
Am 21.06.2018 um 10:10 schrieb Marcin Błażejowski:
>
>
> string desc = "This is something about my foo series"
>
> setinfo foo1 --description=desc
I am with you this should only work for "--description="desc" for
consistency reasons.
It should be noted that the doc only talks about a string (literal) in
double quotes. String variables came later in gretl I think. Then using
--description=desc is ambiguous: Does the user mean the string variable
with name desc, or a literal string with a sloppy use (without the
double quotes)?
So I don't think it's a bug, but I would also be OK to be strict about
requiring the double quotes for literal strings.
> setinfo foo3 --description=@desc
This one works with "@desc" -- which is the standard way I think.
--description=@foostring also works, as long as no spaces are in foostring:
desc = "hello"
setinfo foo3 --description=@desc # works
However, this would stop working when the need for double quotes is
enforced. Artur is right and the safe way is "@desc".
cheers,
sven
12:21 p.m.
On Thu, 21 Jun 2018, Sven Schreiber wrote:
Am 21.06.2018 um 10:53 schrieb Artur Tarassow:
> Hi Marcin,
>
> Am 21.06.2018 um 10:10 schrieb Marcin Błażejowski:
>>
>> string desc = "This is something about my foo series"
>>
>> setinfo foo1 --description=desc
>
> I am with you this should only work for "--description="desc" for
> consistency reasons.
It should be noted that the doc only talks about a string (literal) in
double quotes. String variables came later in gretl I think. Then using
--description=desc is ambiguous: Does the user mean the string variable
with name desc, or a literal string with a sloppy use (without the
double quotes)?
So I don't think it's a bug, but I would also be OK to be strict about
requiring the double quotes for literal strings.
>
>> setinfo foo3 --description=@desc
>
> This one works with "@desc" -- which is the standard way I think.
--description=@foostring also works, as long as no spaces are in foostring:
desc = "hello"
setinfo foo3 --description=@desc # works
However, this would stop working when the need for double quotes is
enforced. Artur is right and the safe way is "@desc".
I think we probably should enforce the "double-quotes needed" rule
for the sake of clarity.
One other point: there's something that was added, experimentally,
some time ago but has never been documented, designed to help when
you want to set an option parameter using an expression rather than
a hard-wired value. This is an "eval" function, as in
string foo = "Some descriptive stuff"
setinfo s1 --description=eval(foo)
or even
strings S = defarray("First thing", "Second thing")
setinfo s1 --description=eval(S[2])
Allin
2:19 p.m.
On Thu, 21 Jun 2018, Allin Cottrell wrote:
On Thu, 21 Jun 2018, Sven Schreiber wrote:
> It should be noted that the doc only talks about a string (literal) in
> double quotes. String variables came later in gretl I think. Then using
> --description=desc is ambiguous: Does the user mean the string variable
> with name desc, or a literal string with a sloppy use (without the double
> quotes)?
>
> So I don't think it's a bug, but I would also be OK to be strict about
> requiring the double quotes for literal strings.
I think we probably should enforce the "double-quotes needed" rule for the
sake of clarity.
Actually that's not so easy. All option parameters are in the first
instance treated as strings by the command-line parser and
double-quotes are just needed to stick together strings with
embedded spaces; they are stripped off before the string is stored.
So I'm not going to attempt this restriction now.
Going back a moment to Marcin's posting, it should be clear that
string desc = "This is something about my foo series"
setinfo foo3 --description=@desc
is not going to work. After string substitution the second line
reads
setinfo foo3 --description=This is something about my foo series
which is then read as setting a description of "This", followed by
uninterpretable trailing junk.
Allin
2:53 p.m.
On 21.06.2018 16:19, Allin Cottrell wrote:
string desc = "This is something about my foo series"
setinfo foo3 --description=@desc
Allin,
since setinfo foo3 --description="@desc" works quite well I think it's
worth to be mentioned in manual for clarification. Ane that is all.
Marcin
--
Marcin Błażejowski
3:09 p.m.
On Thu, 21 Jun 2018, Marcin Błażejowski wrote:
On 21.06.2018 16:19, Allin Cottrell wrote:
> string desc = "This is something about my foo series"
> setinfo foo3 --description=@desc
Allin,
since setinfo foo3 --description="@desc" works quite well I think it's
worth to be mentioned in manual for clarification. Ane that is all.
OK, that's a good idea.
Allin
2498
days inactive
2498
days old
6 comments
4 participants
participants (4)
-
Allin Cottrell -
Artur Tarassow -
Marcin Błażejowski -
Sven Schreiber