<xyscripts> not properly resolved?

[Filehero]

Hi,

don't know wether the following is a bug (by means of unexpected behaviour) or works as designed.

The script example code

Code: Select all

  $cmd = "  load(getScriptPathFromINI());<crlf>  load(getScriptPath());"; 
  msg($cmd);
  load($cmd, , "s");
  


function getScriptPath() {    
    // straight return of the script path, <xyscripts> IS RESOLVED ******
    return "<xyscripts>\files_folders\DatestampMe.xys";
}


function getScriptPathFromINI() {
    
    /*
    [LIST]
    1=<xyscripts>\files_folders\DatestampMe.xys
    */
    // ini provided script path, <xyscripts> IS NOT RESOLVED ******
    return getkey(1, "LIST", "<xyscripts>\libs\scriptList.ini");
}

The abnormality is that once the path of the script to run is read as a key from an ini file, the <xyscripts> variable as leading part of the path is not resolved anymore.
Shouldn't <xyscripts> be properly resolved here as well?

Code: Select all

    /*
    [LIST]
    1=<xyscripts>\files_folders\DatestampMe.xys
    */

Remedy: once <xyscripts> is absent from the path in the ini file reading from INI file works (again).

Code: Select all

    /*
    [LIST]
    1=files_folders\DatestampMe.xys
    */

Filehero

[highend]

It's a string when you read it from a file, not an (internal XY) variable any more. You need to eval() that string to get the variable resolved

[Filehero]

I've skipped noting that I already had tried to eval, but

Code: Select all

 1=<xyscripts>\files_folders\DatestampMe.xys

gives always an overflow error because of the backslashes, whereas

Code: Select all

 1=<xyscripts>

or

Code: Select all

<xyscripts>files_foldersDatestampMe.xys

works.

So I skip the variable (though I prefer the explicit notation over the inbuild implicit one), my generic menu builder (finally, no more menu script gallore) will work without it.

Thanks anyway.

[admin]

Cannot repro.

Can you send me that scriptList.ini file?

[PeterH]

I think the .ini is the mentioned:

Code: Select all

    [LIST]
    1=<xyscripts>\files_folders\DatestampMe.xys

(I hope without /* and */ )

And highend is right: here <xy...> is just a string, and must be resolved by eval() after it has been read.

[Filehero]

Can you send me that scriptList.ini file?

Yes, when back at home.

[PeterH]

Addition: but eval must treat the value as a string (so i.e. \ will not be executed)
Instead of
return getkey(1, "LIST", "<xyscripts>\libs\scriptList.ini");
code
return eval("""getkey(1, "LIST", "<xyscripts>\libs\scriptList.ini")""");
or
return eval(quote(getkey(1, "LIST", "<xyscripts>\libs\scriptList.ini")));

(I hope I counted the ))) correct )

Edit:
return eval("""getkey(1, "LIST", "<xyscripts>\libs\scriptList.ini")""");
is NOT clean as written (there's a function inside the double quotes, while I tested it with a constant). Correct it should be
return eval("""".getkey(1, "LIST", "<xyscripts>\libs\scriptList.ini")."""");
or
return eval('"'.getkey(1, "LIST", "<xyscripts>\libs\scriptList.ini").'"');

[Filehero]

And highend is right: here <xy...> is just a string, and must be resolved by eval() after it has been read.

Actually, I already wanted to reply that to highend's reply: I never use XY's <embedded vars> without quotes, so they are always strings. But eval was never needed to get them resolved by XY.

/e: @Peter, thanks. I will try at home.

Let's wait what Don finds.

[admin]

OK, sorry, all needed info was there, no need to send anything.

You simply do this with your INI value if there is anything to resolve it in:

Code: Select all

$value = eval(quote($value));

As others already said, getkey() will not resolve the string it returns.

[TheQwerty]

FYI: Don't eval when you should set and reprocess:

Code: Select all

$s = '1\2';
  $e = eval($s);
  set $r, $s, 'r';
  echo "String: $s<crlf>Eval: $e<crlf>Set: $r";

Adding quote in eval helps but is easy to forget to do.

[Filehero]

First of all, thanks guys for your help. I even was playing with quotes, but not at the very beginning of the processing chain.

Code: Select all

$value = eval(quote($value));

As others already said, getkey() will not resolve the string it returns.

This looks quite awful. Could you make it supporting "auto-expansion"?

Don't know, wether it breaks backwards compatibility. For whatever reason I - of course! - simply have assumed that <xyvars> get expanded somewhere if they get read with getkey(). Expanding the scope of <xyvars> into the configuration persistency method offered by XY SC would render that "problem" obsolete in an very elegant way.


Otherwise, I would add this little example/explanation as a usage note to the getkey() help.

You simply do this with your INI value if there is anything to resolve it in:

Code: Select all

$value = eval(quote($value));

As others already said, getkey() will not resolve the string it returns.

Cheers,
Filehero

[admin]

First of all, thanks guys for your help. I even was playing with quotes, but not at the very beginning of the processing chain.

Code: Select all

$value = eval(quote($value));

As others already said, getkey() will not resolve the string it returns.

This looks quite awful.

Awful? It looks beautiful to me.

And I find it quite exotic to place XY variables into INI files. I'm not convinced I should add anything to handle this. After all you already can do it now in various ways as shown above.

[PeterH]

Don was a bit faster than me, but anyway:

Sad to say: if you read data from a file you should expect it to be just data - and not to be changed in any way.
If, like here, you have a situation that *you* want to treat some text as a variable and substitute it's value (what, if the string would includ e.g. $a?) *you* have to tell the script that's it that way.
In theorie input-commands *could* have an option to do as you want - but I don't think it makes sense, and is worth it.

Don't forget: even when defining strings in a script *you* decide that variables are resolved: look for the difference between variable in single quoted strings (that's like the situation where you input something from a device) and double quotes (only here "imbedded" variables are resolved).

So as Don said: everything is fine here.

[Filehero]

Jungs, alles ist gut, and I indeed do understand the sense of the eval-statement.

Thanks again.

FH