[F] Filter " " can falsely match " "

(Note: Topic Title is faulty. This forum post form's changed its two consecutive space characters to one, and I can find no way to edit the Topic Title.)

Here, Filter "" falsely matches a track having as its only tag field [EDIT:] TITLE having as value a string having no "", but having "" at start.

[EDIT:]

[EDIT:]
PS Help http://help.mp3tag.de/main_filter.html says

but I take it this is intended to say "...that contain every word or quoted string..." since Help also says

If you want to filter for something like spaces at the beginning of a string you would have to use an expression as the function you use only applies to words. A double-space is no word, a word has to have at least one visible character.

As the screenshot shows, none. But using operator HAS gives the same result.

Cannot verify that: a single space at the beginning of title plus the filter expression
%title% HAS " "
leads to no hits.

Sorry to be unclear. I used TITLE, as per Help's spec http://help.mp3tag.de/main_filter.html "Filter expressions are simple expressions that consist of tag field names, filter keywords and text." and got:

I get the same. I note that this form accords with Help's examples, but not Help's spec.

I get different results for
TITLE HAS " " -> hit (just the one with a leading space)
title HAS " " -> hit (just the one with a leading space)
%title% HAS " " -> no hit
" " -> all tracks with a space in the data somewhere

You did not specify which tag-field exactly should be examined.
There might be some other tag field in the record of tag-fields, which contains two consecutive space characters?

But there seems to be something special, indeed.

TITLE HAS " "
(one space)
... does show the file with TITLE string having only one leading space character.

TITLE HAS " "
(two spaces)
... does show also the file with TITLE string having only one leading space character.

TITLE HAS " "
(three spaces)
does not show the file with TITLE string having only one leading space character.

"%TITLE%" HAS " "
(two spaces)
does not show the file with TITLE string having only one leading space character.

"%TITLE%" HAS " "
(one space)
does show the file with TITLE string having only one leading space character,
and of course all other files having at least one space character in the tag-field TITLE.

This works exact.

TITLE MATCHES "^ "
(one space)
... does show the file with TITLE string having only one leading space character.

TITLE MATCHES "^ "
(two spaces)
... does not show the file with TITLE string having only one leading space character.

DD.20140326.1505.CET

Thanks. FTR, the reply form verifies those four " " as two spaces.

I thought my "its only tag field" made clear there is no other tag field in the track, but I have updated the report to be clearer. Thanks.

Not the forum, but HTML will only display a single whitespace character no matter how many are in the source code. (it's that regexp readibility thing again)

It also does not display tabs (Vert or Horiz), line breaks (LF), new lines (CR).

To display all white space on a HTML document it has to be enclosed in a

 
element.

Not quite. e.g. this forum's HTML displays them fine in TEXTAREA.

Elsewhere, this this forum software needs only to encode repeated space characters appropriately - using &nbsp.

Ah, but a is a form input field not a HTML display element.

There are some deprecated elements that also display as 'plain text', which was intended for displaying code snippets and which displayed by default as "tele-type" characters.

Agreed, but you said HTML not "HTML display element" :slight_smile:

There's some kind of bug here. Here's what I find. I'm not going to go through every permutation for number of spaces and fields with leading and trailing spaces and every other thing. I think that if Florian just knows there's a related bug, he should be able to track it down and fix all instances.

TITLE=xxx (no leading or trailing spaces)

title HAS " " (one space) matches
%title% HAS " " (one space) does not match


And a general comment: I really wish this language would be cleaned up to either require surrounding %% or to not allow them when addressing field contents. The Help shows both, and it's obvious that even the behavior can be affected by which one is used. This needs to be made more rigid.

Ideally, the plain would address the field name, not its contents, while %% would be required when referring to data within the field. Thus, expressions like this would be valid:

%artist% HAS morrison
artist MISSING

and the following would be invalid:

artist HAS morrison
%artist% MISSING

Florian, I am not in the habit of saying "I told you so" :slight_smile: but can I just say you might find it useful to reread the warning I gave you by email on 16/09/2009, before you switched to this new filter syntax. And to reread your reply!

Good luck.

Yes, many scripting errors could be avoided and many life time can be saved, when the Mp3tag's scripting language(s) would not so loose defined as it is.
Much time is lost by the repeated need to try, what is allowed to use, what works now and what does not.

Regarding the filter expression there is defined this rule:
If in HAS/IS/GREATER/LESS/EQUAL/MATCHES contains $ or % it should be enclosed in double quotation marks and will be treated as a format string instead of a tag field name.

Since the given filter examples do not follow this rule, why should the simple user follow?

DD.20140327.1919.CET

Hoy! I do the nit-picking around here if you don't mind. :smiley:

Okay! :slight_smile:

I've fixed this with Mp3tag v2.59.

[2014-04-13]  FIX: filtering for field HAS " " was also matching files without blanks.

Thanks for reporting!

Kind regards
Florian

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.