XYplorer Beta Club

Per128 wrote:Hi,
I'm testing XYPlorer v7.7 under XP64 and have a problem with the following script:
"test_writefile" writefile("temp.txt", "text")

Scripting->Load Selected Script File on the above (contained in <xypath>\scripts\test.xys) gives me:
Scripting error window: "'writefile' is not a valid script command."

The problem is obvious; I get a scripting error on a basic command that should work just fine. A forum search on this revealed nothing of relevance.
Any idea what may be causing this?

Well, if by v7.7 you mean 7.70.0000 the problem is obvious indeed, given that writefile was added in v7.70.0004

Maybe you should update at least to the latest official version (7.80.0000, out since November 6th) and try again

jacky wrote: Well, if by v7.7 you mean 7.70.0000 the problem is obvious indeed, given that writefile was added in v7.70.0004

Maybe you should update at least to the latest official version (7.80.0000, out since November 6th) and try again

Thanks for the reply Jacky.
I upgraded to x7.8, and since all my careful customizations of nearly every aspect of the program are now gone, am I right in assuming the updater has simply overwritten them or is there a backup of my settings somewhere? I don't expect such behavior from an update.
Please let me know if this is too off-tangent.

Per128 wrote:I upgraded to x7.8, and since all my careful customizations of nearly every aspect of the program are now gone, am I right in assuming the updater has simply overwritten them or is there a backup of my settings somewhere? I don't expect such behavior from an update.
Please let me know if this is too off-tangent.

Hi and a belated welcome to the XY forums!

How did you install the update? I use the "install" vers and never had an issue with losing any settings that I'm aware of.

And tangents are fine within reason...

I'm surprised no one has run into this, goes back to at least v7.80 (though then E fails too).

TheQwerty wrote:I'm surprised no one has run into this, goes back to at least v7.80 (though then E fails too).

Code: Select all

"Math Fail"
  $a = -2 * -1;
  $b = -1 * -2;
  $c = ($a == $b);

  $d = -2;
  $e = -1 * $d;
  $f = $d * -1;
  $g = ($e == $f);

  Text("A = -2 * -1 = $a<crlf>B = -1 * -2; = $b<crlf>C = (A == B) = $c<crlf><crlf>D = -2 = $d<crlf>E = -1 * D = $e<crlf>F = D * -1 = $f<crlf>G = (E == F) = $g<crlf><crlf>WTF?");

Porca miseria! Fix comes... Thanks!

Scripting has a really annoying behaviour of reporting about perceived errors that aren't errors at all. Allow me to elaborate...

I have a central dump repository where files are transferred to in the first instance and then sorted according to their names. To do this sorting, I have a script file that I run on this collection of files. The problem is that, when parsing the script, XYplorer does not proactively take into account that the order of precedence should stem from a top-down approach.

Let me illustrate with an example. I have it so if a file has a string "abc" in it then it's moved into a folder called "ABC". However, I also would like for it to move a file with a string "123" in the name into a folder called "123". Those are not a problem when "abc" and "123" are not both in the name of a file. The hiccup arises when both are present. To handle this hiccup, I have the pattern match for "123" above that of "abc" in the script file, because I'd rather a file with both went to "123" than "ABC". The scripting engine, however, is not intelligent enough to comprehend that this was done on purpose. Yet 2 warning screens pop up for every instance where "abc" and "123" (the former changes frequently, the latter stays the same) are both present.

This behaviour is, while with the best intentions, is really undesirable, not in the least because of tediousness of clicking through the "error" screens. What's even more frustrating is that it actually does what it's supposed to i.e puts a file with "123" into "123" yet feels the need to warn me twice about it. While not a bug in the parsing of the script, it's an error in the "thinking" i.e the scripting engine doesn't say to itself: "This user put "123" above "abc", so it is more likely than not that he wants me to put file with "123" into "123" than "ABC" even though both are present. I'll be a clever engine and not disturb my user, because technically there is no problem".

Would you please be kind enough implement either a way to suppress warnings on a per-script basis or change the logic of how the top-down approach is interpreted by the scripting parser? I'll be very grateful

Since I doubt XY's scripting engine is actually the one doing the thinking in this whole thing, it might not be the one to blame. Of course, you stay as vague as possible so we don't know what your script actually is/does, nor do we have any ideas what those errors/warnings you get are.

One thing I can tell you though is that I have a script that does something similar to what you're describing here : I select a bunch of files, and it will move each one into a folder whose name is deducted from the file's own name. And it does work, without warnings or a cautious scripting engine wondering if I meant to do what the script says to do

jacky wrote:Since I doubt XY's scripting engine is actually the one doing the thinking in this whole thing, it might not be the one to blame. Of course, you stay as vague as possible so we don't know what your script actually is/does, nor do we have any ideas what those errors/warnings you get are.

I'd have pasted the script file but I don't have it on my portable installation. Will do when I can.

jacky wrote: One thing I can tell you though is that I have a script that does something similar to what you're describing here : I select a bunch of files, and it will move each one into a folder whose name is deducted from the file's own name. And it does work, without warnings or a cautious scripting engine wondering if I meant to do what the script says to do

Sounds similar in terms of functionality, but it's the coding of it that matters. Can you create a file that satisfies 2 or more sorting criteria and apply the script to that file? No warning messages?

OK, here's the sample of the script. I'm not pasting the whole of it because it's quite long. So a file that has both "720p.HDTV" and "Heroes" in its name would cause the two error messages: one about file not existing (because the 720p one has already been moved so the Heroes one can't be executed and the second one about the moveto command either having failed or be cancelled (it's the former since that file has already been moved).

Well, so it is your script, trying to move the same file twice. And obviously, after the first time the file isn't there/doesn't exists anymore, hence error messages...

Maybe try something like that:

Many thanks jacky! Ideally, I hoped not to have to redo my script and just to be able to suppress the errors, that's a quick and dirty way We get warning messages in lots of apps and usually there's a tickbox (or a button) that says "Do not remind me again" or something of similar extent.

One further note of scripting bugs, my script that worked in the previous beta (.0108) stopped working in current beta (.0109). Here it is:

Don't know why it would stop working, but you should definitely quote your argument/filter: --

Unrelated: found a bug in scripting: From the help Works as expected. Now this should do the same, but doesn't as continue; seem to escape the else block only, and we need to do continue 2; to make it work properly... FYI the key is the else, it works fine within an if block. However, from an elseif block it is buggy as well...

jacky wrote:Don't know why it would stop working, but you should definitely quote your argument/filter:

Code: Select all

selfilter '*.r??', f;

Since it's a loose match, I didn't realise that quoting it is necessary. Nothing was mentioned in the changelog in terms filtering behaviour being changed.

zer0 wrote:

jacky wrote:Don't know why it would stop working, but you should definitely quote your argument/filter:

Code: Select all

selfilter '*.r??', f;

Since it's a loose match, I didn't realise that quoting it is necessary. Nothing was mentioned in the changelog in terms filtering behaviour being changed.

There was indeed a side effect in a recent change. Fixed in next upload.

But, the dot (concatenator) in your pattern is reason enough to quote it. Because *.r?? is resolved to *r??.

admin wrote:There was indeed a side effect in a recent change. Fixed in next upload.

But, the dot (concatenator) in your pattern is reason enough to quote it. Because *.r?? is resolved to *r??.

Then the wiki (http://88.191.26.34/XYwiki/index.php/Sc ... _selfilter) needs to be changed, because, in an example mention in it, 1.gif (unquoted) is resolved as *1.gif* because no wildcards are mentioned in that pattern, so they're added automatically. However, there are wildcards in my pattern, so why is the effect of the concatenator different depending on presence of wildcards?