Hi,
I'm working on RFE4940735, which adds -R/-r support to grep. I've
been thinking about the ARC that was created for this, general
usability, and also how it fits
into a broader context of potentially adding -r to other utilities and
was looking for some feedback. Roland Mainz had emailed me and
mentioned shells-discuss at opensolaris so I thought I would ask for
opinions from that group as well.
Background
------------
The man page diff for the ARC includes
-H If the -R option is specified and a symbolic link referencing
a file of type directory is specified on the command line,
grep will search all files in the directory referenced by the
symbolic link.
-L If the -R option is specified and a symbolic link referencing
a file of type directory is specified on the command line or
encountered during the traversal of a file hierarchy, grep
will search all files in the directory referenced by the
symbolic link.
-R
-r Recursive. grep descends through the directory, and
any subdirectories. When a symbolic link is encountered,
no recursion takes place. Unless a -H, or -L option
is specified, the grep utility will not follow the symbolic
link to any other part of the file hierarchy.
(and some other options such as context for search results(-A/-B/-C),
but I'm leaving these off the table for now).
Cindy Eastham also mentioned a '-d' option for not crossing file system
boundaries when recursing, which I agreed to implement, we will need to
get the ARC case updated.
Questions
----------
Some questions I had are (all assuming -R/-r has been used on the
command line):
1) Does -r imply that sym links that point to files should always be
followed (except if the link points to an object off the current file
system and -d is specified)
My Comments: I think it does, but would like clarification in case I am
misreading the doc.
2) Should directory objects themselves be passed to the grep routine?
My Comments: Solaris' grep has never seemed useful to me for searching a
directory object, I've always needed to use
"strings /directory | grep foo" if for some chance I wanted to examine
directory contents. ( GNU grep prints a 'binary file matches' message if
using options that examine directory objects.)
3) The default behavior of not following symbolic links into
directories seems odd to me for commands that are oriented around file
contents. While I understand that find, du, etc care a lot about
files/directories/sym links, etc, it seems to me that the behavior is
because of their purpose of examining/reporting/acting on about file
meta data (size, type, ownership, etc). For commands that are oriented
around file content (grep in this case, but also if '-r' was added to
say awk or cat, etc), it seems to me that users typically care about
examining file content and by default don't care if a path examined
included a sym link or not.
3.1) The -H option seems especially odd to me since it deals with a case
where the user specifically mentioned an object on the command line. If
I passed a sym link to a directory as an argument to grep -r, it seems
that I'm implying that I want whatever the object is or points to to be
searched, not just to skip it unless I remember to add -H. Basically I
think the common use case is that if people have specified an argument
on the command line, they don't want to have to care if it is a file,
directory, sym link, etc
Example: (Trying to find any perl references in files in /etc or /bin
without knowing that /bin is actually a sym link to /usr/bin)
cd /
grep -r perl bin etc
My Comments: without -L or -H my interpretation is that 'bin' should be
silently skipped since it is a sym link, which seems counter-intuitive to me
4) I'm also struggling a bit with the concept of embedding all the logic
for performing the file system walk should be inside each of the 6 grep
variants ((e|f)grep and xpg4 (e|f)grep) instead of in some other library
that they link with. While it can certainly be done, it doesn't seem to
bode well for code-reuse and ease of future maintenance.
--
William D. Hathaway email: william.hathaway at versatile.com
Solutions Architect aim: wdhPO
Versatile, Inc. cell: 717-314-5461
