Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
libglobbing does not support escaped slashes #2297
Currently the new libglobbing does not support escaped slashes. This is because the library relies on,
The regular expression
Thank you! Yes, I like the regex idea. It also has advantages for other tools (like a "mmv"-like functionality). And it is in general very useful for external tools if we can specify a regex.
The regex does not seem to be complete, though. Single backslashes are generally allowed (to be used literally) but in some situations they are used for escaping (., %), see also src/libs/elektra/keyname.c
I modified the regex. It now should always match a full key name part. The only escaping rule taken into account is the one concerned with slashes. Meaning the regex could be used as a substitute for
The cases of
Thank you, looks much better. Yes, the goal for the regex is only to split into key names part, not to implement the semantics.
I wonder if we should provide "elektraKeyGlob" because with regexs this would be quite inefficient (compilation of regex for every key). With larger specifications, most of the execution time is already spent within the spec plugin matching key names, so we should make sure that we do not make the situation worse (I assume fnmatch is already highly optimized).
I'll say the lib is experimental for now and that anything can change in the next version.
Yes the regex would be compiled for every call of
According to this its more that POSIX
Which is why I now think, using regex without allowing regex input from the user might not be a good idea. However, for mmv-like functionality which needs back references, using PCRE might be worth thinking about. PCRE with its many extensions, would also allow direct translation of
We could always provide a second version
For the spec plugin, this would not be a problem because
For example when the KeySet contains
When matching against the pattern
Here the restriction of
The question is if we should provide such a function then.
I do not know about which "POSIX" implementation they refer to. They seem to use "Microsoft Visual C++", maybe it is only a problem of this specific implementation.
I think the musl-systems will not so happy about the dependency. Because libglob is a quite basic library hopefully used by basic plugins (like spec) in the future. But as it is not in the core, we actually could use PCRE if there is no way around (e.g. because of performance reasons.)
Maybe it is better then to use a more simple and not-so-direct regex?
I would very much prefer to have only one API and implementation. Otherwise it is too difficult to maintain. "kdb mmv" is nice to have and should not influence elektraKsGlob too much. In particular it is not good if we leak too many internals. It should not matter if internally regex, fnmatch or a trie is used. Such implementation details are up to you anyway. If we use a trie, we might be able to reuse the existing trie. I think, however, that a trie implementation might be quite cumbersome (even with restrictions). For me glob -> regex seems to be the easier way to go.