Programmable column operator problem

Discussion & Support for xplorer² professional

Moderators: fgagnon, nikos, Site Mods

Post Reply
otlaolap
Silver Member
Silver Member
Posts: 236
Joined: 2007 Aug 11, 21:37

Programmable column operator problem

Post by otlaolap »

I am trying to use the programmable column to see if a file consists of one of three specific contents. I want to detect files that contain exactly "|-RGS-|" (without the quotes), "|-LJS'|", and "|-LJS-|-RGS=|". There are no line-end or carriage-return characters in the file.

I have failed to make the GREP function work. In part I suspect that the "|" is troublesome. I cannot find a grep expression that will do an exact compare of the file -- it can find contents within the file, but I cannot get the start-at-the-start ^ operator and the end-at-the-end $ operator to work, possibly because what I am searching for includes "|" and I don't know how to express that. And I also don't know how to express in a single grep expression something that would catch all three exact cases, and without this I fall in to the problem I am actually describing, below.

So I am trying to use fbytes, and here is where there is, as far as I can tell, a bug in the programmable column support. The following expression works well:

(file2("fbytes(0,8)",${Path}+mid(${Name},1,len(${Name})-4)+".tag")="7C.2D.52.47.53.2D.7C")

It gives me a 0 or a 1 as a result. For simplicity let us call the above expression "X". If I put X + X in the programmable column operation field, I get a syntax error "wrong function argument" at the second occurrence of "file2". Likewise if I put X & X in the operation field, or X | X. To make this explicit,

(file2("fbytes(0,8)",${Path}+mid(${Name},1,len(${Name})-4)+".tag")="7C.2D.52.47.53.2D.7C")+(file2("fbytes(0,8)",${Path}+mid(${Name},1,len(${Name})-4)+".tag")="7C.2D.52.47.53.2D.7C")

gives a syntax error, and I don't know why.

Any thoughts? or, even better, a better and more elegant solution to what I am trying to do?
otlaolap
Silver Member
Silver Member
Posts: 236
Joined: 2007 Aug 11, 21:37

Re: Programmable column operator problem

Post by otlaolap »

I have managed finally to sort out a GREP solution. The following

file2("GREP('^\|\-RGS\-\|$|^\|\-LJS\-\|$|^\|\-LJS\-\|\-RGS\-\|$')",${Path}+mid(${Name},1,len(${Name})-4)+".tag")

gives me a 0 or 1 depending on whether there is or is not a match. (Since the documentation says that GREP returns "a positive number" on a match, I will add a test for 0 versus not zero to make sure that the answer is 0 or 1.) So I can work with this and do not think I need further help. But I still think there is a problem with using the file2 operator more than once as shown in the first post above.
User avatar
nikos
Site Admin
Site Admin
Posts: 15771
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Programmable column operator problem

Post by nikos »

whoa, you get a PhD in programmable column for this one :)
why are you checking a DIFFERENT file though with a fixed extension?
I have FILE2 and FILEPROP() meant for a (future) use comparing files
otlaolap
Silver Member
Silver Member
Posts: 236
Joined: 2007 Aug 11, 21:37

Re: Programmable column operator problem

Post by otlaolap »

Nikos, I have an enormous number of photos (as have you). They are of many different file types -- .jpg, .bmp, .png, .mp4, .avi, and so on. In a separate .tag file I store what I want to use as one-word tags about a photo (there may be more than one tag). I know about your tagging method, and I know (to some level of experimentation and detail) about auxiliary data streams, but they have proven unsatisfactory. ADS are not preserved reliably by copy programs and so I abandoned an earlier method of tagging files that relied on them. And I absolutely hate the idea that tagging a photo in some way or other alters the file with the photo at all (jpgs for example can hold annotations in the file as you know). Consequently this stupid second file. With X2 and AHK this is working well enough.

But why the programmable column? The actual column generator reads

token("===---===,===tag===,===zap===",",",1+exists(${Path}+mid(${Name},1,len(${Name})-4)+".tag")+(file2("GREP('^\|\-RGS\-\|$|^\|\-LJS\-\|$|^\|\-LJS\-\|\-RGS\-\|$')",${Path}+mid(${Name},1,len(${Name})-4)+".tag")<>0))

which yields one of three flags: no tag file; any tag except for specific ones; and a specific tag file (one of three). The tag files can contain multiple tags, and this is why the start-of-file and end-of-file operands are used to make sure, for the three specific files, that it contains only the specific tags.

But why do this at all? That is where one of your other X2 features is very handy. The programmable column output is used by color coding on the files when they are being displayed for sorting and thinking. The tag files themselves are hidden files and so do not show up in normal operation. There are colors for videos, for photos without tags, for photos with tags, and for photos with one of the three specific tags shown above. In thumbnail mode (which is what one uses of course with pictures), and with tag files hidden, color coding works really well.

If only your color coding operand included the full set of programmable column functions, I could drop the programmable column and do this inside the color coding domain.

It's a kludge, for sure, but it's my kludge (appropriate smiley here), and it works well enough for me.
User avatar
nikos
Site Admin
Site Admin
Posts: 15771
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Re: Programmable column operator problem

Post by nikos »

:thumbup:
Post Reply