[sweeper] Can anyone post a couple of examples pls for "fileexists".

[boris]

I want to find a programme with the same title (not filename) in another folder, specifically.

Thank you.

 

[Black Hole]

That won't be easy, I don't think sweeper is set up for recursive searching through the directory tree. I think you will need a command line script for that.

 

[boris]

Thank you for getting back, it's not a recursive search though.

I'm looking for a file of a particular name (with wild cards for the numeric part iof the filename) in a particular folder which has no sub folders.

Should be something like:

fileexists [Films]/%asfilename:%%candidate:*

where %candidate is my programme title.
%asfilename:%%candidate:* should be my basic filename and
[films] is the directory being searched.

The fileexists does give a hint that it will search folders but I can't find the format which works for the parameters.

Just to be clear: If a programme is recorded called "boris", which would normally get put in the root Videos folder, I want to find out of there is another file called boris_XXXX_XXX.ts in [Films]. (XXX being the usual numerics).

 

[af123]

fileexists [Films]/%asfilename:%%candidate:*

fileexists doesn't currently support wildcards so it's looking for a file specifically called 'boris*'

28/10/2016 12:22 - Processing [fileexists {[Films]/%asfilename:%%candidate:*}]
28/10/2016 12:22 - fileexists([Films]/%asfilename:%%candidate:*) 
28/10/2016 12:22 - Expanded [%%candidate] -> [boris] 
28/10/2016 12:22 - asfilename([Films]/%asfilename:%%candidate:*) -> [[Films]/boris*] 
28/10/2016 12:22 - Expanded [[Films]/%asfilename:%%candidate:*] -> [[Films]/boris*] 
28/10/2016 12:22 - FILEEXISTS(/media/My Video/[Films]/boris*) 
28/10/2016 12:22 - Nomatch

I'll have to make a change to sweeper to support what you want to do.

 

[boris]

LOL! I'd just run a couple of tests to come to the same conclusion.
I searched for a full (and exact) filename that I know to be there, and then replaced one character with a single character wildcard ?
I am sure I've seen a post that does the same thing though, perhaps it was just in the same directory.

That change would be much appreciated.
Is there a place on the wiki where we can start filling in the use and abuse of the commands?

 

[af123]

Here's the required change in /mod/webif/plugin/sweeper/auto.hook

--- auto.hook~
+++ auto.hook
@@ -549,7 +549,12 @@
        }
        log "  FILEEXISTS($str)" 2

-       return [file isfile $str]
+       set matches [glob -nocomplain \
+           -directory [file dirname $str] \
+           -tails [file tail $str]]
+       log "     Matches($matches)" 2
+       return [expr [llength $matches] > 0]
}

I'll bundle this into a Sweeper update.

 

[boris]

Thank you, so much much appreciated.
Wasn't expecting that quick a turn around!

Adding it now.
Actually if I add the patch, will your update routine refuse to overwrite it? Hope not.

 

[prpr]

Actually if I add the patch, will your update routine refuse to overwrite it? Hope not.

No, it'll overwrite whatever you've changed when the package installs.

 

[boris]

Works fine; thank you.

 

[Black Hole]

fileexists doesn't currently support wildcards so it's looking for a file specifically called 'boris*'

What happens now if you really do want to look for a file called 'boris*' and not 'boris2'?

 

[Trev]

That could be true of any search engine that uses wildcards unless you put quotes around it.

 

[Black Hole]

That's as may be, but my point is does the sweeper mechanism support some kind of literal interpretation when one wants a literal interpretation? My concern is that patching it to support one user's requirements may have alienated other users - specifically some may have existing rules which now no longer work properly, at best requiring their rules are modified and at worst no longer working at all (because there may be no modification that will restore exact previous functionality).

 

[af123]

That did cross my mind. However, the fileexists condition is pretty new and most likely only in use by people who have loaded the example dedup/tidy rules for which it was originally created. The chances of it being in active use where it could trigger the specific edge case are remote and it is not unreasonable to expect that it would work with wildcards. You're right though, there is no way to restore the exact previous behaviour at present.

I'm wondering what would be a better alternative.. perhaps something which returns the number of files matching a pattern would be useful.

 

[Black Hole]

Can't quotes be used to literalise the search string? Or escape the wild card characters to make them literal? Or maybe just restore fileexists to the previous implementation and introduce fileexists_wild for the version that can accept wildcard characters (obviously the latter has the least impact on existing users, because the new functionality has a new function).