XYplorer Beta Club

Does something appear if, still in the folder of es, you type in the AB and press Enter?

Jepp, 5 first folders/locations of the 'everything list'

Very weird. Anyway this should work

Marco wrote:Very weird. Anyway this should work

Nope, doesn't work.

Tried it with 0.92 and it works.
0.94 also works

Does it work if you set $unicode to TRUE? (I mean, with the 0.96 that you can find on the first page)

Marco wrote:Does it work if you set $unicode to TRUE? (I mean, with the 0.96 that you can find on the first page)

No, didn't work, still empty results.

0.95 also didn't work!

I'm sorry, I'm out of possible solutions. Setting $unicode to true calls the same command line of 0.94, I don't understand why it doesn't work anymore and, most of all, why I can't repro.

Last try with your debug: the stepping dialogs are as below:Last try with your debug, the stepping dialog are as below:still some more but i guess that's enough to debug?

Marco, try this. Make 2 files:
Pokémon àbc.txt
Pokémon abc.txt

Now use Everything (without the script) and do a search:
Pokémon àbc should result in both files showing up
diacritics:(Pokémon àbc) should result in nothing showing up
diacritics:Pokémon abc with both showing up again
diacritics:Pokémon diacritics:àbc should result in only 1 file showing up.

The diacritics: is a modifier that should be prepend to EVERY search term. That's the only way it worked for me.

Also we should really say what version of Everything and es.exe we are using. In each case, I have just updated to the newest version today and the script still does not work even though the older version does. Also, I have Unicode in the script set to on as I did the first time I downloaded the script heh. There is a couple other things that are odd but I will write them later since I need to leave right now.

Did some more testing. The runret command does not seem to return correct results which resulted in a paper file with links to file that does not exist. Basically I tested es.exe directly for the search term Pokémon àbc which resulted in both files showing up as expected (NOTE that I have diacritics option turned off for now and Unicode set to FALSE). Tellilng XYplorer to display the results of the variable $results after the runret command, I got: and obviously these two files does not exist. This is the bug that's probably related to the bug that you wrote about related to the Test•file.txt. Basically CMD displays the dot correctly but the XYplorer does not process it correctly for the runret command. This is confirmed by another test that I ran on a certain drive. On this particular drive, running the search term pokemon directly in Everything resulted in 392 results. I then ran the search term using I'm also using Notepad2-mod which will automatically tell me when a file is changed and will update it accordingly. In this case, the PAPER file that was created by the script first showed up 392 lines just as expected. However, XYplorer will then display only 388 files since the missing 4 files have diacritics in them and since the runret command did not process the output correctly, these files does not exist and therefore were removed by XYplorer. After switching to another tab, XYplorer finalized the trimming and the paper file will end up with only 388 lines. Now with the Unicode option set to TRUE, XYplorer's list now become only 386 files and I don't understand why. However, the paper file initially was written with 392 so there's still something funky going on with the Unicode output.

Also, there needs to be some kind of check and processing if there are no results. For some reason at the moment, when you enter a search term that has no results, the script would write the paper file with content i≫. You can test it yourself. Just search for something that does not exist and then open up that paper file. Instead of it being empty, you got some stuff in it. Usually XYplorer would then clean it up since those "items" don't exist but there are times it does persist and legitimate items then become appended to it which ends up making that particular item not existing and later removed for being a zombie.

Another problem with the Unicode option on is that the paper file created has some weird stuff prepended to it. For example, the result of a certain search should have been: but what I got was this: After stripping the first 3 byte from the file, the file then become valid HOWEVER the file encoding is not in UTF-16 but as UTF-8 so it still won't work well in XYplorer. So I re-encoded the file from UTF-8 to UTF-16 and then it works perfectly.

I'm really sorry that my post ended up so long... but that's the result of my findings thus far. Basically runret is not processing things correctly. And the Unicode output directly to file is creating files with wrong encoding.

Hmm... So even though I said the old versions works, I just retested them and they actually do have the same problem with the Unicode issue when creating a paper file.

Also Marco, as an extension to the post where I was talking about how Everything was using the modifier diacritics:, now try this:
Create a new file named (Pokémon àbc).txt and (Pokémon abc).txt
Now do a search directly in Everything with term diacritics:(Pokémon àbc)
Hey look! Both files showed up!
But diacritics:(Pokémon diacritics:àbc) only had (Pokémon àbc).txt showed up. Weird.

Seems like the space will always be treated as a separator so any space must be prepended with diacritics: for it to work as expected. Also, parenthesis are taken as literal.

Hi Enternal, first of all thanks for the time you spent for the analysis.

I did the same four tests you did with the Pokémon text files, and then it occurred to me that in Everything GUI I had this option set (Tools > Options > General > Search): Allow round bracket grouping. That's the culprit. If I disable it, I get your behaviour, if I enable instead everything works as a mathematician would expect. Apparently is disabled by default. I will then add on the first post and in the code comments that it should be enabled, because it allows a way more compact syntax. Technically, there would be no problem in prepending diacritics: in front of each word at the script level, but I would have to add more code and the resulting query would be very long and hard to decipher. No good, definitely not on my plans.

Re runret: your understanding is right, basically CMD displays the dot correctly but the XYplorer does not process it correctly for the runret command. More importantly, and this is the bad part, XY somehow swaps certain characters (see the dot bug) with other characters that look similar, but they're not the same. When I implemented the runret route to get the results, I added a check: if the console returns at least a question mark then it means there's unicode in the results that can't be processed correctly by the console, and so it falls back to output redirection to disk. However I didn't expect that XY itself could misinterpret the output console, I thought that was fixed. And since no question marks are returned the script thinks everything is fine. I had a hard time myself figuring out why a search result with a dot was unopenable.
I see two options:
-dropping the runret route tout-court
-adding more smartness by changing the logic, from the current "if there's a question mark then use redirection" to "if there's something beyond ASCII and some punctuation, not ?, then use redirection". The subtle problem is: how can I be sure that ASCII is unaffected by the dot bug? Ok, I could create a test file, do here the check and then ask you, since you're on a different locale, to do the same and if it works then there should be no problem. Only thing is that ASCII is a bit restrictive, and the check would entail a long line of code - I'm a fan of elegant and compact code instead, you all know.

UTF8: I did not change anything in that line, so I don't understand why now you don't get a proper BOM anymore. Maybe Don changed something without reporting it in the changelog? Try this: What does XY report as raw content in the Raw View IP? It should say "EF BB BF". If not we have another problem. Would this give the right BOM?

Btw, simple script to check if ASCII doesn't give problems

PS: wait a sec, if the console returns Pokémon but runret shows it as Pokemon, then there's nothing I can do, one-to-one correspondence is broken even for ascii.

Marco wrote:PS: wait a sec, if the console returns Pokémon but runret shows it as Pokemon, then there's nothing I can do, one-to-one correspondence is broken even for ascii.

Yep pretty much! Until that bug you reported is resolved and how runret deals with these types of characters, you won't be able to do much at the moment. Although interestingly Japanese characters are showing up fine. Only characters with diacritics showed up incorrectly.

EDIT: About the Unicode issue, what exactly is this for? What is annoying is I can't figure a way to make the CMD codepage to UTF-16 since that code page is only available to managed applications according to Microsoft. It is was available to all, you could have simply used 1200 instead of 65001 for UTF-8.

Anyway, in the mean time, to solve that issue with the Unicode, I did this: Basically I created a temp file that is in UTF-8, load it into a variable and then "rewrite" the file in UTF-16. I had to explicitly tell XYplorer to read the file in UTF-8 because otherwise the automatic detection does not seem to work the way I expected it to. What do you think? So far the amount of items that show in Everything is the same as the amount of items that show up in XYplorer's paper folder and that's for items with Unicode in their names. So it seems to be working now.

Anyone willing to by a little quick guinea pig? Mainly sinilill and binoculars222. Please test the script to see if the Unicode change I made works for you.