Guild of Writers

I find the PageEditor tool to be of immense value. Whenever the question comes up, "How did Cyan do that?" I call up that PRP and find that out. It's also useful to look for examples when coding up something similar in AlcScript, especially responder modifiers. However, after manually searching through object after object (and PRP after PRP) for the example I'm looking for, it gets tedious really fast.

So, I'm requesting a command-line search mechanism. The usage would be:

prpgrep <substring> <path-to-dat-folder>


[Note for non-Unix people: 'grep' is a command used to search for a substring in a collection of files.]

The utility would loop through each PRP file, expand each object into an internal XML buffer (like it does in PageEditor) and report on any case-insensitive matching substring. For example, suppose I issue the command:

prpgrep kEnable "c:\Program Files\URU\dat"

It would report each usage of kEnable by listing the PRP file name, PRP object type, name and the text of the line, such as:

Kadish_District_kdshPillars.prp: ResponderModifier: cRespSecretDoorClose: <hsBitVector>kEnable </hsBitVector>

It may take a while to execute, but it would be much faster than doing it manually. I think it would be incredibly useful and save a bunch of time.

What do you think? Is it do-able?

For extra credit, the path argument could be made optional. The first time the command is used, the user would have to provide the path. prpgrep would store it somewhere (e.g. Windows registry). The next time the command is used, if the path argument is skipped, it just retrieves the stored value.

Oooh, I do like this idea, and it would make searching though PRP files much much easier.

It could also take really really long amounts of time to unpack and search through the PRC in memory... probably have to unpack one object at a time >.>

Hmm, I really like this idea too... However, I think I might make a couple of proposals before actually implementing it:

1) Personally, I think it would be better to specify a set of files rather than a path... While it's true that you may want to search *every* PRP file in a path, you may also only want one PRP, or the files from an age, or ... Therefore, I would propose making the command line syntax: prpgrep PATTERN FILE [FILE2 [...]] . The downside of this is that I've recently discovered that Windows doesn't do file globbing the same way that Linux does (namely: Windows doesn't do it at all), so I'd have to parse glob patterns in the program for the Windows build... However, I'll make sure that happens this time (and probably update the other command line utilities to do the same)

2) The key advantage of grep is not just that it searches for substrings, but rather that it searches for Regular Expressions... There are C++ libraries to handle regex that I can use for this, but if the regular expression functionality isn't actually needed, I'd just as soon not deal with linking in yet another library . I'd like to know what opinions people have on this point before I go about implementing the tool...


Note that proposal 1 excludes the possibility of storing the path somewhere, but personally I've never liked the idea of command-line tools storing persistent data, unless that's their express purpose... Also, using the Windows Registry would, of course, not be a viable option for Linux or Mac users . And for what it's worth, I think Paradox's idea to only look at the PRC code for one object at a time is probably better, simply because you can report line offsets based on individual objects (which is more likely what the user will want) instead of from the whole PRP File's PRC source... However, the PRC extraction can definitely be done purely in RAM for this tool, and *probably* wouldn't be too unreasonably slow... Slow, yes, but not unreasonably so

I can give up saving the path in order to have a file match argument. That way, you can reduce the time of the search significantly. Bring on the globbing!

And I don't need regex capability... yet.

Ok, it turns out that adding proper globbing support on Windows is easier than I realized (at least if you use Visual Studio as your compiler)... So, this latest release now has globbing support for all of the libPlasma command line tools, including the new prpgrep. Enjoy

PS: For anyone else wondering how to do this, MSDN points to an alternate _setargv which handles globbing, and can be linked into any app by simply linking with Setargv.obj, which comes with Visual Studio... Just in case anyone was wondering

I finally got a chance to try this out. It's terrific! And it's fast when I can narrow down the number of PRPs to search using a wildcard file pattern.

Thanks for making this tool a reality, Zrax!