fix(filter): keep the whole regex when it contains a colon - #3674

The defect

GlancesFilter.filter splits the input on every colon and keeps only the second field (glances/filter.py:113):

new_filter = value.split(':')
...
self._filter = new_filter[1]
self._filter_key = new_filter[0]

So everything after the second colon is discarded. Measured on develop:

And the truncated filter then rejects the process it was written for:

>>> f.filter = 'cmdline:C:/Program Files/.*'
>>> f.is_filtered({'cmdline': 'C:/Program Files/app.exe'})
False

The truncation is silent. The leading fragment is usually still a valid regex — C compiles fine — so the except around re.compile at :134 never fires. The user gets an empty process list, no error, and one debug-level log line.

On Windows this is every absolute path, because each one carries a drive colon. It is not Windows-only, though: it also truncates URLs, IPv6 literals, and any foo:bar process name.

The fix

value.split(':', 1).

I looked at the repo's own split_esc (glances/globals.py:677) first, since plugins/plugin/model.py:1069 already uses it for a key:value pair. It is the wrong tool here: it escapes on backslash and removes the escape characters from its result, which would mangle a Windows path regex like C:\Windows\.*. The separator in this field needs no escaping — a filter key never contains a colon — so plain maxsplit is both smaller and correct. There is a test pinning that backslashes survive.

Verification

Windows 11, Python 3.14.7.

tests/test_core.py     46 passed, 6 skipped     (identical to develop — no test moved)
ruff check             All checks passed

Mutation-checked, after confirming the edit applied: restoring split(':') fails test_020_filter with AssertionError: 'C' != 'C:/Program Files/.*'.

Tests

Extends the existing test_020_filter, which already exercises GlancesFilter this way, with three cases: a path regex carrying a drive colon, the same shape without a path (name:foo:bar, so the case is not read as Windows-only), and a backslash-bearing regex asserting the escapes survive the split.

One thing I did not change: a filter written as a bare regex with a colon in it, such as http://.*, still has its scheme read as the key. This fix stops the regex being truncated but does not disambiguate that; validating the key against the known process fields would, and that is a larger decision than this one-token change.