The attached patch allows to pass several options -e as one would do with standard grep(1) command.
This review comes from the following PR :
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238380
Details
Details
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
Could you upload a diff with full context?
| usr.bin/grep/zgrep.sh | ||
|---|---|---|
| 145 | The indentation is off here. | |
| usr.bin/grep/zgrep.sh | ||
|---|---|---|
| 92 | I don't think this will work if the pattern contains any whitespace. The shell will tokenize $2 when it builds the new grep_args, so things like zgrep -e "foo bar" won't work anymore. You can play some ugly games with eval to make it work I think. To handle -e, write arg="\"$2\"" and add it to grep_args. Then, when constructing the grep command, use eval to expand the arguments. Maybe there is a better way but I don't really see it. (Rewrite in lua? :) | |
| 147 | I think you could combine the two cases by converting a pattern passed as a positional argument to a -e parameter. | |
Comment Actions
Hi Mark,
Thanks a lot for your feedback.
Good catch! Damn, you are right, my patch does not work when grepping patterns that include whitespaces :/ Using eval would work but is a no go for me as it would handle grep arguments in an insecure way : one would, for example, be able to fork a subshell by passing it as a grep pattern.
We could replace spaces in grep patterns with character classes such as :blank: to make the final grep pattern space-free (such as 'foo[[:blank:]]bar') but this is really ugly (and it includes the tab character). After several tries, I could not find a simple, elegant way to work around that problem. Maybe you're right, it would be better to leave the tool as-is and replace it "some day" (TM) by a re-written version, maybe in a language more fit for arguments manipulation ?
Comment Actions
Close for now as the suggested patch does not handle spaces in file names (see discussion).