gaze from support for -q (output suppression) and return status checking
gaze has a global -q option flag, but current gaze from ignores this and
outputs regardless. gaze from also returns 0 regardless of whether a match was
found or not, so it's currently impossible to test if a given file was provided
by a spell without either testing the output directly or using low-level
sorcery functions directly. This situation is non-optimal. The attached patch
implements logic in the show_from() function to test if -q was passed and
suppress output accordingly, and also causes show_from to always return the
proper exit status (regardless of -q presence).
#1 Updated by Jaka Kranjc over 4 years ago
The saved rc after xargs is not guaranteed to be correct, as xargs returns 0 only if all the invocations of the command return 0. So let's say it is a big install (requiring multiple invocations) and the first run did find something (grep rc 0), but the last didn't. This would result in a final rc of 1.
I suggest you make it do exactly what you described - return depending on the match.
#2 Updated by flux control over 4 years ago
I don't actually follow what you mean about big installations causing multiple invocations. Have you actually tested whatever potential problem you are seeing? Or is it strictly theoretical at this stage? However, I tried working this out anyway.
Unfortunately, it won't actually work. The problem is caused by the -q option to grep not being guaranteed as consistent, and therefore in order to have gaze from respect the -q flag to gaze, the output has to be redirected to null when the -q flag is passed to gaze. Since the output is redirected to null, $match will always be a null string when gaze is passed -q. This effectively makes gaze -q worthless for what it was intended. Unless grep gains consistency, this is seemingly the only way to make it work, unless we want to start using temporary files (quite messy IMHO, but I suppose that's an "open" alternative).
If you have other ideas for how to solve this mess though, do let me know. Also, if you can shed some light on what you mean about the multiple invocations, perhaps I can do some corner-case testing.
#3 Updated by flux control over 4 years ago
Also, just a curiosity, but is there a particular reason that grep -e is used? The comments in the source only mention guarding against patters that begin with a dash. This can be guarded against more easily by using the double-dash trick to signal that any further command-line arguments are not flags. Example:
grep -- "-pattern" FILE
e get us anything other that dash-initial pattern matches? I doubt switching to '-' would really net any real improvement, but I'm just wondering if there is something additional that -e is guarding against that isn't documented in the comments.
#4 Updated by Jaka Kranjc over 4 years ago
What I meant by big installations was anything that would cause xargs to create more than one grep invocation (due to commandline length limits), sometimes causing unwanted return values, as explained above.
You can silence gaze later, as it is clear the matches are needed to determine the return value first. When in quiet mode, just don't print them.
There is nothing special about -e that I would know of.