[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 20 May 2008 19:53:07 -0600
> > I was trying to do grep -fl <filename1> <filename2>
> > grep: l: No such file or directory
> "-fl" works fine, because "-f" means "Look in the named file for a list
> of expressions to search for"; then we have to know what the name of the
> file is, and POSIX says that it follows "-f" immediately, so
> grep -fexpressions files
> grep -f expressions files
> this is based on POSIX basis rather than on GNU standards which has
> bundling(meaning thereby -xvf == -x -v -f)
If "expressions" is a file of expressions then we are in agreement so
far. (But tar's -f option takes a file argument.) And in your
example above -fl signifies that "l" is the filename for the -f option.
> Furthermore, the Linux Standard Base specifies that grep in this
> instance works the same way as the Single UNIX Specification:
There it says "grep is as specified in the Single UNIX Specification
but with differences as listed below." and does not list -f in the
list of differences. Therefore the LSB does not change the semantics
of the SUS -f option. Which means that the LSB neither adds to nor
subtracts from this discussion about GNU grep.
> The Single Unix Specification states that
> Guideline 5:
> Options without option-arguments should be accepted when grouped
> behind one "-" delimiter.
> -f is *not* an option without an option-argument, and therefore can't be
> "grouped", or bundled.
Right. It can't be bundled. "-lf FILE" is the same as "-l -f FILE"
but "-fl FILE" isn't the same as "-f FILE -l". We seem to be in
agreement on this point.
The standards say:
grep [-E| -F][-c| -l| -q][-insvx] -e pattern_list...
grep [-E| -F][-c| -l| -q][-insvx][-e pattern_list]...
grep [-E| -F][-c| -l| -q][-insvx] pattern_list[file...]
Read one or more patterns from the file named by the pathname
Since the -e pattern_list isn't present but -f pattern_file is present
we are looking at the second synopsis case. The -f must be followed
by the pattern_file. A optional -l option if present must appear
before it in the program argument list.
> In other words, you will break the specifications if you change grep to
> work this way: you will have a broken grep.
I don't understand your reasoning. Can you provide some examples
illustrating where you say that GNU grep is broken?
The case you ask about above with "grep -fl FILE1 FILE2" is not a case
that illustrates GNU grep being broken. It is behaving as documented
by both GNU documentation and POSIX documentation. It is behaving the
same as SysV grep and BSD grep. Since all three of those flavors of
program are operating the same way it seems likely that they are
behaving as desired.
Note that POSIX grep isn't V7 fgrep just as POSIX sh isn't V7 sh.
Because you are asking about bundling -fl together with the pattern
file later in the argument list this implies to me that you want the
undocumented V7 semantics of fgrep/egrep. It is a stretch for me to
assume you are talking about V7 semantics but V7 grep had interesting
argument processing that allowed the above. POSIX doesn't allow this
and neither is it advantageous to implement as a GNU extension since
it isn't compatible with other greps such as SysV and BSD grep.
In V7 fgrep due to the implementation of the way program arguments
were processed the following was allowed with both of these examples
being the same (undocumented) behavior:
fgrep -f -l PATTERNFILE FILE
fgrep -l -f PATTERNFILE FILE
But note that the following ignored the "l" option. V7 fgrep didn't
handle bundled options. These following were all the same.
fgrep -f PATTERNFILE FILE
fgrep -fl PATTERNFILE FILE
fgrep -fqwerty PATTERNFILE FILE
This case above was fixed in later versions of grep such as SysV grep
and BSD grep. System V grep and BSD grep and GNU grep behave the same
in regard to the behavior of the -f option.