Dear all,
I am afraid that my problem has a simple solution, but I failed to find it. After loading some libraries with:
gSystem->Load("myLib.so");
I want to check the actual location of the loaded libraries; I am trying to accomplish this by using TSystem::ListLibraries(const char *regex = “”), but with partial success. I.e., if I use:
gSystem->ListLibraries();
I obtain a complete list of all the loaded libraries. If I replace “” with any kind of regular expression, the result is always empty. For example:
gSystem->ListLibraries(".*")
returns 0 matches, while I naively expected its output to be the same as in the first line. I see this behavior even when I do not load any library, and start root with the -n option (to skip the rootlogon.C file). Would it be possible to point me to some successful examples of using the regex parameter? Thanks for any suggestions! Best,
I investigated a bit further, and it seems that the “/” characters in the libraries’ names (path names) make the RexExp inoperant. I will see how to fix that and propose a PR. Thanks to have seen it.
The following script shows the issue. The string s1 contains a / and Index with a regulars expression * does not work whereas with s2, which has no /, it is fine:
@couet Please note that the TSystem::ListLibraries method description explicitly says that it expects a “wildcard expression”, not a “regexp”. That’s how it always was. Don’t make changes that will break “backward compatibility”.
I don’t really know how to force ROOT “wildcard expression” to treat “/” as a regular character. Maybe the original author of this code knows it.
I would use TSystem::GetLibraries, with an empty “regexp” parameter, and then parse the returned character string myself (with a regular “regexp”, not a “wildcard expression”).
@couet This output is terribly wrong. The regexp "Core" should return nothing (there is no library with the full file name “Core”. Only a regexp like ".*Core.*" should return both libraries.
That’s exactly the problem the regular expression like ".*Core.*" does not work as a regular expression as it is a wildcard (cf my previous post) and it returns nothing. (bug ?) … now gSystem->ListLibraries("Core") returns nothing either (as before).
But, with the PR, when you put the flag to kFALSE then regexp is considered as a string and you get the two libraries. The PR does not change anything compared to the current behavior. Seems to me it is buggy but you said we should not change it and you proposed a quite complex workaround.
Now I added the possibility to change the flag. So we can tell the method to not consider regexp as a wildcard. The logic is already encoded in GetLibraries, this flag only allows us to trigger it. By doing that (see the new help) you can display the two “Core”.
So, maybe stop calling this parameter “regexp”, because it’s misleading. Change its name to “substring”. Then, when the “wildcard = true” (the default now), it will be treated as a ROOT “wildcard expression”, and when “wildcard = false”, it will be treated as an ordinary “substring” (i.e., it’s never a “regular expression”).
I think the core of the problem now is that the TSystem::GetLibraries method names its parameter “regexp”, but it’s never a “regular expression” (again, it’s either treated as a ROOT “wildcard expression” or as an ordinary “substring”).
Well, maybe the original author of the ROOT “wildcard expression” source code knows how to force it to treat “/” as a regular character.
See my “ListLibraries.cxx” macro. It really takes a “regular expression” as a parameter.
let me thank you for your interest in finding a solution! From a user’s standpoint, it would be great if the name of the parameter were updated, to clarify what, by default, the parameter represents, and have the possibility (e.g., via an additional flag, as you both suggested) to pass a real regular expression. That would make the command very powerful and flexible. I believe I did try both ".*" (reg exp) and "*" (a wildcard expression?), and in both cases the command returned 0 libraries found, hence my original message. Thank you very much again for your suggestions, and proposals for a fix! Best,
Alberto