Unexpected behavior with ifpath

Hi and happy holidays!

I'm reporting a few ~bugettes based on things found in this thread...

Given the following code when run as a Left double-click action:

[code]@ifpath:.(cbr|cbz)
show

@ifpath:else
"/system\mspaint.exe" {f}[/code]
You'll find a few unexpected behaviors.

First, the ifpath test here is in a weird partially functioning state... in this case, for what the OP in the linked thread wanted - it works as desired. Image files inside of a CBR or CBZ archive get opened in the internal picture viewer, and images OUTSIDE of such paths get opened in MS Paint. Would seem fine right?

However, flip the logic around like so:

[code]@ifpath:.(cbr|cbz)
"/system\mspaint.exe" {f}

@ifpath:else
show[/code]
...and you'll find that Opus is ignoring the actual command inside a positive ifpath test. I.e. above, it's still opening the image in the internal picture viewer instead of MS Paint. It seems the only reason it was working as "intended" before was because it was falling back on default action of opening the image in the viewer rather than paying any attention to the 'show' command. But yet, it does seem to be sort of working, because when returned to the original code, it obviously knows when I've opened an image file NOT located in the ifpath wildcard test, and opens the image in MS Paint.

Confusing...

Also, the ifpath test itself as written above catches cases where it's a regular folder with an extension of either .CBR or .CBZ, as opposed to an actual archive file. However, if you change the test to @ifpath:.(cbr|cbz)[b][/b]... adding the trailing backslash causes it to STOP working on regular folder paths, but yet still works in it's confusingly half successful way when used with archive files.

Huuuuuh? What's up with all that?

@ifpath may not be testing the path you want if the file has to be extracted to temp for the {f} code. There's a chicken & egg problem there so I'm not sure exactly what's happening, but scripting exists now to solve this kind of problem in a far better way. I'd recommend using scripting to have more control, and leave @ifpath for very simple cases.

Scripting also solves the issue of determining whether you're in an archive or a folder with a name that's like an archive.

I suspected the temp folder extraction behind the scenes might be at play in the other thread yeah, but - and you KNOW that I am personally more than happy to script away :slight_smile: - but... a few observations:

  1. It's already sort of working. I would argue that since NEGATION of the ifpath test undoubtedly works (i.e. from the first code quote - image files that do NOT match the ifpath test get opened according to whatever you put in the ifpath:else clause), that this means the POSITIVE result for the ifpath test is implicitly working, no? The commands inside that positive clause simply aren't being run, and eval of the {f} control isn't involved here... get rid of it and you will find that no command you stick inside the positive test clause gets run at all, and it should.

  2. If it is in fact something to do with the extraction of the archive behind the scenes - I'd expect Opus to mask that from users insofar as how we can then use internal commands to take action. Just like it visually looks like we're in the same path instead of being sent to a temp folder.

You know me... I'm not super passionate about it, and I have reason to script around this stuff for an alternate idea for the OP anyway, but I don't think it's an overly complicated use of existing commands that should be viewed as out of scope. We can otherwise work with archives ~as folders, so I would expect attempts like this to be considered in the category of "very simple cases" - simply testing whether the path I'm in is inside an archive or not.

Secret to a happy life: Pretend branching logic no longer exists outside of scripting. :slight_smile:

It always ends up less complicated to just use a script, in my experience. No reason to waste braincells on @ifpath, which is a legacy thing.

(Similar with DOS Batch branching logic. Scripting can do the same things in a much cleaner way, with fewer surprises. Every time I think "it's really simple, I'll just use DOS Batch to keep things simple" I end up shooting myself in the foot and wishing I'd gone straight to a script.)

Fair enough - I just figured it was a simple enough case that non-scripters might enjoy the use of it working as expected.

I'll happily trade any and all thought cycles from this report for increased consideration of my request for backlist/fowardlist history in scripts :slight_smile:.

</shameless_plug>