From sacadmin Thu Jan 27 11:17:54 2005 Received: from spartan.SFBay.Sun.COM (spartan [129.146.88.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RJHsac020651; Thu, 27 Jan 2005 11:17:54 -0800 (PST) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j0RJGu2e000889; Thu, 27 Jan 2005 11:16:56 -0800 (PST) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10/Submit) id j0RJGuIb000885; Thu, 27 Jan 2005 11:16:56 -0800 (PST) Date: Thu, 27 Jan 2005 11:16:56 -0800 (PST) From: Don Cragun Message-Id: <200501271916.j0RJGuIb000885@spartan.SFBay.Sun.COM> To: PSARC@sac.sfbay.sun.com Cc: Cynthia.Eastham@Sun.COM Subject: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] Subject: PSARC FastTrack [02/03/2005]: Add ggrep context and recursive search features to grep. Status: RO Content-Length: 6022 Template Version: @(#)sac_nextcase 1.55 08/11/04 SMI Copyright 2005 Sun Microsystems, Inc. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Add ggrep context and recursive search features to grep. 1.2. Name of Document Author/Supplier: Author: Cynthia Eastham 1.3 Date of This Document: 27 January, 2005 4. Technical Description 1. Overview As part of the UNIX 200x project, many utilities were updated to allow recursively descending through file hierarchies. Unfortunately, the *grep* utility was not one of these. CR 4940735, RFE *grep* endless customer complaints about missing 'grep -r', documents the need for just such a capability, as well as the ability to print after, trailing, and surrounding context around matching lines. 2. Release Binding The project team requests a micro release binding. 3. Details The -R option enabling recursively descending through file hierarchies exist in many Solaris utilities, including chgrp, chown, du, ls, and cp. In addition, to align with SUSv3 standards, symbolic link support options, -H and -L, were added to these utilities. The grep utility, however, was not updated to allow recursion with symbolic link support. The -R option is not in SUSv3 as it wasn't in SUSv2 and wasn't in any approved amendment to POSIX.2-1992 and wasn't proposed as a necessary feature that was in scope for SUSv3. However, GNU versions of grep do contain the -R and -r options allowing recursion. CR 4940735, RFE *grep* endless customer complaints about missing 'grep -r' documents the need for options to allow a user to recursively search through a file hierarchy. This CR also requests the ability to print context surrounding a match be added with options similar to the -A (trailing context), -B (leading context), and -C (output context) options provided in GNU versions of grep. In addition, Solaris command utilities which support recursively descending through file hierarchies also allow users to specify to follow symbolic links while recursing, therefore options [-H | -L] will be also be added to 'grep'. The following options will be added to /usr/bin/grep, /usr/xpg4/bin/grep, /usr/bin/egrep, /usr/xpg4/bin/egrep, /usr/bin/fgrep, and /usr/xpg4/bin/fgrep: -A number Prints number lines of trailing context after the matching lines. Places a line containing -- between contiguous groups of matches. -B number Prints number lines of leading context before the matching lines. Places a line containing -- between contiguous groups of matches. -C number Prints number lines of leading context before the matching lines and number lines of trailing context after the matching lines. Places a line containing -- between contiguous groups of matches. -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. Specifying more than one of the mutually-exclusive options -H and -L will not be considered an error. The last option specified will determine the behavior of the utility. Specifying more than one of the options -A, -B, or -C will not be considered an error. The last option specifying the number of lines of leading context and the last option specifying the number of lines of trailing context will determine the behavior of the utility. 4. Conflicts Note that the -H and -L options were chosen to provide symbolic link support for consistency as they are the options added to other utilities to align with the SUSv3 standard. However, they conflict with the GNU version of grep, where -H prints the filename for each match, and -L suppresses normal output and instead prints the name of each input file from which no output would normally have been printed, stopping on the first match. The GNU version of grep, with POSIXLY_CORRECT set in the environment, does not change the behavior of the -H or -L options. 5. Exported Interfaces ______________________________________ | Interface |Classification| |_____________________|______________| |/usr/bin/grep, | | |/usr/xpg4/bin/grep, | | |/usr/bin/egrep, | Standard | |/usr/xpg4/bin/egrep, | | |/usr/bin/fgrep, & | | |/usr/xpg4/bin/fgrep | | |except -A, -B, -C, | | |-H, -L, -R, and -r | | |options | | |_____________________|______________| |-A, -B, -C, -H, -L, | | |-R, and -r options | Evolving | |_____________________|______________| 6. References - CR 4940735 RFE *grep* endless customer complaints about missing 'grep -r' - The SUSv3 specifications of grep are available on-line at: http://www.opengroup.org/onlinepubs/007904975/utilities/grep.html - The GNU grep (version 2.5) man page available in Solaris 10 (build 74L2) at /usr/sfw/man1/ggrep.1. The observations documented in the project document regarding GNU grep behavior were based on this version of GNU grep and documentation. A reference copy of this man page is provided in the case directory. - The latest GNU grep documentation available on-line at: //http://www.gnu.org/software/grep/doc/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Thu Jan 27 12:33:20 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RKXKac025216 for ; Thu, 27 Jan 2005 12:33:20 -0800 (PST) Received: from heckle (vpn-129-150-25-142.SFBay.Sun.COM [129.150.25.142]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id j0RKWG2X819078; Thu, 27 Jan 2005 12:32:17 -0800 (PST) Message-Id: <200501272032.j0RKWG2X819078@jurassic.eng.sun.com> Date: Thu, 27 Jan 2005 12:32:43 -0800 (PST) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] To: PSARC@sac.sfbay.sun.com, dwc@spartan.eng.sun.com Cc: Cynthia.Eastham@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: AivJKvbstxV6iFNIyC5m2Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Status: RO Content-Length: 78 Why "-r" and "-R"? From everything I can tell, these are identical. - jek3 From sacadmin Thu Jan 27 12:49:10 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RKnAac026155 for ; Thu, 27 Jan 2005 12:49:10 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0RKmDuL006824 for ; Thu, 27 Jan 2005 12:48:13 -0800 (PST) Received: from fe1.sun.com ([192.18.108.78]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j0RKmDdt013140 for ; Thu, 27 Jan 2005 13:48:13 -0700 (MST) Received: from conversion-daemon.fe1.sun.com by fe1.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) id <0IAZ00601T7J5000@fe1.sun.com> (original mail from Ienup.Sung@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 27 Jan 2005 13:48:13 -0700 (MST) Received: from sun.com ([129.150.27.115]) by fe1.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IAZ00AJDTSCP710@fe1.sun.com>; Thu, 27 Jan 2005 13:48:13 -0700 (MST) Date: Thu, 27 Jan 2005 12:49:22 -0800 From: Ienup Sung Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] In-reply-to: <200501271916.j0RJGuIb000885@spartan.SFBay.Sun.COM> To: PSARC@sac.sfbay.sun.com Cc: Cynthia.Eastham@Sun.COM Reply-to: Ienup.Sung@Sun.COM Message-id: <41F953D2.5070509@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200501271916.j0RJGuIb000885@spartan.SFBay.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 Status: RO Hi Don, I'm not quite sure if I need to to bring this issue up since we can always tell people to use /usr/sfw/bin/ggrep and so on but it seems we have conflicts on the -H and the -L options with GNU grep which has: -H, --with-filename print the filename for each match -L, --files-without-match only print FILE names containing no match Would it be worthwhile thing for us to even think about, for instance, an additional flag or environment variable to allow switching between GNU grep behavior and SUSv3 -R with -H/-L behavior? With regards, Ienup From sacadmin Thu Jan 27 12:59:00 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RKx0ac029011 for ; Thu, 27 Jan 2005 12:59:00 -0800 (PST) Received: from chaos (chaos.SFBay.Sun.COM [129.146.88.112]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id j0RKw2mt826198; Thu, 27 Jan 2005 12:58:02 -0800 (PST) Date: Thu, 27 Jan 2005 12:51:54 -0800 (PST) From: Cynthia Eastham Reply-To: Cynthia Eastham Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] To: "Joseph E. Kowalski III" Cc: PSARC@sac.sfbay.sun.com, dwc@spartan.eng.sun.com, Cynthia.Eastham@sun.com In-Reply-To: "Your message with ID" <200501272032.j0RKWG2X819078@jurassic.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO > > Why "-r" and "-R"? From everything I can tell, these are identical. > > - jek3 > Yes, they are identical. The GNU version of grep supplies both the -r and -R. The bug report documents the need for -r. Typically (I say typically, as I know of at least one instance - diff - where -r is used), the standard (SUSv3) requires commands to provide the -R to recursively descend. Cindy From sacadmin Thu Jan 27 13:09:13 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RL9Dac029583 for ; Thu, 27 Jan 2005 13:09:13 -0800 (PST) Received: from 129.146.86.198 (braveheart.SFBay.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0RL8GOx830167; Thu, 27 Jan 2005 13:08:16 -0800 (PST) Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] From: Darren J Moffat To: Ienup.Sung@Sun.COM Cc: PSARC@sac.sfbay.sun.com, Cynthia.Eastham@Sun.COM In-Reply-To: <41F953D2.5070509@sun.com> References: <200501271916.j0RJGuIb000885@spartan.SFBay.Sun.COM> <41F953D2.5070509@sun.com> Content-Type: text/plain; charset=iso-8859-15 Organization: Sun Microsystems, Inc. Message-Id: <1106860095.12451.100.camel@braveheart.SFBay.Sun.COM> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 27 Jan 2005 13:08:16 -0800 Content-Transfer-Encoding: 7bit Status: RO On Thu, 2005-01-27 at 12:49, Ienup Sung wrote: > Would it be worthwhile thing for us to even think about, for instance, > an additional flag or environment variable to allow switching between > GNU grep behavior and SUSv3 -R with -H/-L behavior? We already have that environment variable it is called $PATH. This is the perfect case of why we have /usr/sfw/bin [1], unlike many of the other things that are in /usr/sfw/bin but really shouldn't (IMO) be there. It should be /usr/sfw/bin/grep and /usr/bin/grep, just like we have /usr/xpg4/bin/grep already. [1] though in *this* case it should IMO really be /usr/gnu/bin/grep because we are talking about the GNU environment not freeware stuff we want at External taxonomy and thus out of the path. -- Darren J Moffat From sacadmin Thu Jan 27 13:39:16 2005 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RLdGac000628 for ; Thu, 27 Jan 2005 13:39:16 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0RLcJhG012324 for ; Thu, 27 Jan 2005 13:38:19 -0800 (PST) Received: from fe3.sun.com (fe3.Sun.COM [192.18.108.80] (may be forged)) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0RLcJVu016989 for ; Thu, 27 Jan 2005 14:38:19 -0700 (MST) Received: from conversion-daemon.fe3.sun.com by fe3.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) id <0IAZ00301W3J3Y00@fe3.sun.com> (original mail from Ienup.Sung@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 27 Jan 2005 14:38:19 -0700 (MST) Received: from sun.com ([129.150.27.115]) by fe3.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IAZ006XCW3UDV10@fe3.sun.com>; Thu, 27 Jan 2005 14:38:19 -0700 (MST) Date: Thu, 27 Jan 2005 13:39:28 -0800 From: Ienup Sung Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] In-reply-to: <1106860095.12451.100.camel@braveheart.SFBay.Sun.COM> To: PSARC@sac.sfbay.sun.com Cc: Cynthia.Eastham@Sun.COM Reply-to: Ienup.Sung@Sun.COM Message-id: <41F95F90.5010606@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200501271916.j0RJGuIb000885@spartan.SFBay.Sun.COM> <41F953D2.5070509@sun.com> <1106860095.12451.100.camel@braveheart.SFBay.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 Status: RO I'd like to say I don't disagree and one could also always specify absolute pathnames such as /usr/sfw/bin/ggrep but frankly the $PATH isnt' really easy to edit back and forth, esp., in interactive shellenvironment and hence suggested if the project team would be willing to have an additional flag or environment variable such as GNU_ON or GNU_BEHAVIOR that can be used for all other possible and similar cases. With regards, Ienup Darren J Moffat wrote: > > We already have that environment variable it is called $PATH. > > This is the perfect case of why we have /usr/sfw/bin [1], unlike many of the other things that are in /usr/sfw/bin but really shouldn't (IMO) be there. It should be /usr/sfw/bin/grep and /usr/bin/grep, just like we have /usr/xpg4/bin/grep already. > > [1] though in *this* case it should IMO really be /usr/gnu/bin/grep because we are talking about the GNU environment not freeware stuff we want at External taxonomy and thus out of the path. From sacadmin Thu Jan 27 13:51:13 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RLpDac001232 for ; Thu, 27 Jan 2005 13:51:13 -0800 (PST) Received: from 129.146.86.198 (braveheart.SFBay.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0RLoGJx845120; Thu, 27 Jan 2005 13:50:16 -0800 (PST) Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] From: Darren J Moffat To: Ienup.Sung@Sun.COM Cc: PSARC@sac.sfbay.sun.com, Cynthia.Eastham@Sun.COM In-Reply-To: <41F95F90.5010606@sun.com> References: <200501271916.j0RJGuIb000885@spartan.SFBay.Sun.COM> <41F953D2.5070509@sun.com> <1106860095.12451.100.camel@braveheart.SFBay.Sun.COM> <41F95F90.5010606@sun.com> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1106862616.12451.128.camel@braveheart.SFBay.Sun.COM> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 27 Jan 2005 13:50:16 -0800 Content-Transfer-Encoding: 7bit Status: RO On Thu, 2005-01-27 at 13:39, Ienup Sung wrote: > I'd like to say I don't disagree and one could also always specify absolute > pathnames such as /usr/sfw/bin/ggrep but frankly the $PATH isnt' really > easy to edit back and forth, esp., in interactive shellenvironment and hence > suggested if the project team would be willing to have an additional flag or > environment variable such as GNU_ON or GNU_BEHAVIOR that can be used for > all other possible and similar cases. So then you end up with GNU_ON, XPG4_ON, XPG5_ON, XPG6_ON,.... Sorry this is wrong. For the specific case of GNU vs other there is already solution that has been common practice in the GNU world since at least SunOS 4.x days: thus: You have /usr/gnu/bin/grep You also have /usr/bin/ggrep If you always was GNU then you do PATH=/usr/gnu/bin:/usr/bin, if you just sometimes want to GNU the you use ggrep. $PATH is the way we have been doing this and I don't think this case should change that. -- Darren J Moffat From sacadmin Thu Jan 27 13:52:42 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RLqgac001303 for ; Thu, 27 Jan 2005 13:52:42 -0800 (PST) Received: from heckle (vpn-129-150-25-142.SFBay.Sun.COM [129.150.25.142]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id j0RLphJd845889; Thu, 27 Jan 2005 13:51:45 -0800 (PST) Message-Id: <200501272151.j0RLphJd845889@jurassic.eng.sun.com> Date: Thu, 27 Jan 2005 13:52:11 -0800 (PST) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] To: PSARC@sac.sfbay.sun.com, Ienup.Sung@sun.com Cc: Cynthia.Eastham@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VQg7r/P0uJsVC1Xi/qEdZA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Status: RO Content-Length: 1335 I'll cast my vote with Darren. The bug here is thqat we've polluted /usr/sfw, but that's not fatal. Specific behavior flags are a complication we don't need and I would suspect would be a source of nittling bug reports. Let's spend our meager enhancement dollars where they provide the maximal gain. - jek3 > I'd like to say I don't disagree and one could also always specify absolute > pathnames such as /usr/sfw/bin/ggrep but frankly the $PATH isnt' really > easy to edit back and forth, esp., in interactive shellenvironment and hence > suggested if the project team would be willing to have an additional flag or > environment variable such as GNU_ON or GNU_BEHAVIOR that can be used for > all other possible and similar cases. > > With regards, > > Ienup > > > Darren J Moffat wrote: > > > > We already have that environment variable it is called $PATH. > > > > This is the perfect case of why we have /usr/sfw/bin [1], unlike many of the other things that are in /usr/sfw/bin but really shouldn't (IMO) be there. It should be /usr/sfw/bin/grep and /usr/bin/grep, just like we have /usr/xpg4/bin/grep already. > > > > [1] though in *this* case it should IMO really be /usr/gnu/bin/grep because we are talking about the GNU environment not freeware stuff we want at External taxonomy and thus out of the path. > From sacadmin Thu Jan 27 14:02:44 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RM2iac003934 for ; Thu, 27 Jan 2005 14:02:44 -0800 (PST) Received: from heckle (vpn-129-150-25-142.SFBay.Sun.COM [129.150.25.142]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id j0RM1jLX848877; Thu, 27 Jan 2005 14:01:46 -0800 (PST) Message-Id: <200501272201.j0RM1jLX848877@jurassic.eng.sun.com> Date: Thu, 27 Jan 2005 14:02:12 -0800 (PST) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] To: PSARC@sac.sfbay.sun.com, Ienup.Sung@sun.com Cc: Cynthia.Eastham@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: af03G/o79zCqlJTkCP3iow== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Status: RO Content-Length: 498 > From: Ienup Sung ... > but frankly the $PATH isnt' really easy to edit back and forth, ... It can be (if there is only one or two things you what to toggle) .... SANE_PATH=/usr/bin:/usr/sbin XPG4_PATH=/usr/xpg4/bin:/usr/bin:/usr/sbin GNU_PATH=/usr/sfw/bin:/usr/bin:/usr/sbin I_MUST_BE_NUTS_PATH=/usr/xpg4/bin:/usr/sfw/bin:/usr/bin:/usr/sbin PATH=$SANE_PATH now switching paths is as easy as toggling the environment variables you've suggested: $ PATH=$GNU_PATH - jek3 From sacadmin Thu Jan 27 14:17:16 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.57] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RMHGac004594 for ; Thu, 27 Jan 2005 14:17:16 -0800 (PST) Received: from 129.146.86.198 (braveheart.SFBay.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j0RMGI5U853298; Thu, 27 Jan 2005 14:16:18 -0800 (PST) Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] From: Darren J Moffat To: "Joseph E. Kowalski III" Cc: PSARC@sac.sfbay.sun.com, Ienup.Sung@Sun.COM, Cynthia.Eastham@Sun.COM In-Reply-To: <200501272201.j0RM1jLX848877@jurassic.eng.sun.com> References: <200501272201.j0RM1jLX848877@jurassic.eng.sun.com> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1106864178.12451.158.camel@braveheart.SFBay.Sun.COM> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 27 Jan 2005 14:16:18 -0800 Content-Transfer-Encoding: 7bit Status: RO On Thu, 2005-01-27 at 14:02, Joseph E. Kowalski III wrote: > > From: Ienup Sung > ... > > but frankly the $PATH isnt' really easy to edit back and forth, ... > > It can be (if there is only one or two things you what to toggle) .... Or use shell aliases. I think we have beaten on this enough, all interactive shells have plenty powerful enough features to deal with this we don't need to add yet more rope in this area. In fact I pretty sure than in zsh I could even make this context sensitive, eg if an earlier command in a pipe is a GNU one or I'm in a GNU looking directory use GNU :-) [ implementation of said hackiness left for someone looking for a usless Friday hack contest ]. -- Darren J Moffat From sacadmin Thu Jan 27 14:24:20 2005 Received: from spartan.SFBay.Sun.COM (spartan [129.146.88.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RMOKac004707 for ; Thu, 27 Jan 2005 14:24:20 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.88.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id j0RMNM2f003264; Thu, 27 Jan 2005 14:23:22 -0800 (PST) Message-Id: <200501272223.j0RMNM2f003264@spartan.SFBay.Sun.COM> Date: Thu, 27 Jan 2005 14:23:22 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] To: PSARC@sac.sfbay.sun.com, Ienup.Sung@sun.com Cc: Cynthia.Eastham@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3AlthEoeDTgpJtPQx/jO/Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Ienup, I agree with Darren and Joe. Furthermore, there is some evidence in the GNU world that the POSIX meaning of -H and -L (and maybe even -P) will be used consistently in the future and that current uses of those option letters will be changed. (There is already notice that the GNU -H option to ls will change in this direction.) I discussed this with Cindy before she submitted this case. We explicitly do not want to align with the current -H and -L options in ggrep since they are likely to change in the future (and, we don't have any indication yet of what the new option letters will be). When GNU added the POSIXLY_CORRECT environment variable, it was a huge mistake. (They thought they could request that POSIX conforming applications define this environment variable to get POSIX conforming behavior. The standard explicitly states that applications must not be required to set nonstandard environment variables to get standards-conforming behavior.) I will fight any attempt to add anything like GNU_ON or GNU_BEHAVIOR to alter the behavior of the Solaris grep family (or any other set) of Utilities. Sincerely, Don > >I'll cast my vote with Darren. The bug here is thqat we've polluted >/usr/sfw, but that's not fatal. Specific behavior flags are a complication >we don't need and I would suspect would be a source of nittling bug >reports. Let's spend our meager enhancement dollars where they provide >the maximal gain. > >- jek3 > >> I'd like to say I don't disagree and one could also always specify absolute >> pathnames such as /usr/sfw/bin/ggrep but frankly the $PATH isnt' really >> easy to edit back and forth, esp., in interactive shellenvironment and hence >> suggested if the project team would be willing to have an additional flag or >> environment variable such as GNU_ON or GNU_BEHAVIOR that can be used for >> all other possible and similar cases. >> >> With regards, >> >> Ienup >> >> >> Darren J Moffat wrote: >> > >> > We already have that environment variable it is called $PATH. >> > >> > This is the perfect case of why we have /usr/sfw/bin [1], unlike many of the >other things that are in /usr/sfw/bin but really shouldn't (IMO) be there. It >should be /usr/sfw/bin/grep and /usr/bin/grep, just like we have >/usr/xpg4/bin/grep already. >> > >> > [1] though in *this* case it should IMO really be /usr/gnu/bin/grep because >we are talking about the GNU environment not freeware stuff we want at External >taxonomy and thus out of the path. From sacadmin Thu Jan 27 14:32:42 2005 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0RMWfac004978 for ; Thu, 27 Jan 2005 14:32:41 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0RMViuL022214 for ; Thu, 27 Jan 2005 14:31:44 -0800 (PST) Received: from fe3.sun.com (fe3.Sun.COM [192.18.108.80] (may be forged)) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j0RMViVu026384 for ; Thu, 27 Jan 2005 15:31:44 -0700 (MST) Received: from conversion-daemon.fe3.sun.com by fe3.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) id <0IAZ00401XN2KL00@fe3.sun.com> (original mail from Ienup.Sung@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 27 Jan 2005 15:31:44 -0700 (MST) Received: from sun.com ([129.150.27.115]) by fe3.sun.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IAZ00688YKVDV20@fe3.sun.com>; Thu, 27 Jan 2005 15:31:44 -0700 (MST) Date: Thu, 27 Jan 2005 14:32:53 -0800 From: Ienup Sung Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] In-reply-to: <200501272151.j0RLphJd845889@jurassic.eng.sun.com> To: "Joseph E. Kowalski III" Cc: PSARC@sac.sfbay.sun.com, Cynthia.Eastham@Sun.COM Reply-to: Ienup.Sung@Sun.COM Message-id: <41F96C15.1070108@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200501272151.j0RLphJd845889@jurassic.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 Status: RO Content-Length: 682 Joseph E. Kowalski III wrote: > I'll cast my vote with Darren. The bug here is thqat we've polluted > /usr/sfw, but that's not fatal. Specific behavior flags are a complication > we don't need and I would suspect would be a source of nittling bug > reports. Let's spend our meager enhancement dollars where they provide > the maximal gain. > > - jek3 Thanks for your messages. I'd like to just bow out now for this case. I was just hoping what we can do to somehow merge what we have and what open source has to offer and my last a couple of emails were small rudimentary attempts on the issue I'm sure many have tackled quite sometime ago and by now. With regards, Ienup From sacadmin Fri Jan 28 03:01:35 2005 Received: from bu-ewat02-01.uk.sun.com (sm-ewat02-01 [129.156.199.2]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0SB1Yac024436 for ; Fri, 28 Jan 2005 03:01:34 -0800 (PST) Received: from sun.com (watford-109.UK.Sun.COM [129.156.199.109]) by bu-ewat02-01.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j0SB0XZh028051; Fri, 28 Jan 2005 11:00:33 GMT Message-ID: <41FA1A60.8090608@sun.com> Date: Fri, 28 Jan 2005 10:56:32 +0000 From: Jeremy H. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Cragun CC: PSARC@sac.sfbay.sun.com, Cynthia.Eastham@sun.com Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] References: <200501271916.j0RJGuIb000885@spartan.SFBay.Sun.COM> In-Reply-To: <200501271916.j0RJGuIb000885@spartan.SFBay.Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Don Cragun wrote: > 3. Details > The -R option enabling recursively descending through file hierarchies > exist in many Solaris utilities, including chgrp, chown, du, ls, and cp. > In addition, to align with SUSv3 standards, symbolic link support options, > -H and -L, were added to these utilities. Add a note for "-r" too? > -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. Do -H and -L apply with -r too? Should also define behaviour when -R is not specified - "otherwise, this option is ignored"? > > -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. - Jeremy From sacadmin Fri Jan 28 15:29:31 2005 Received: from spartan.SFBay.Sun.COM (spartan [129.146.88.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j0SNTVac015283 for ; Fri, 28 Jan 2005 15:29:31 -0800 (PST) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j0SNSX2e009353; Fri, 28 Jan 2005 15:28:33 -0800 (PST) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10/Submit) id j0SNSX2C009352; Fri, 28 Jan 2005 15:28:33 -0800 (PST) Date: Fri, 28 Jan 2005 15:28:33 -0800 (PST) From: Don Cragun Message-Id: <200501282328.j0SNSX2C009352@spartan.SFBay.Sun.COM> To: Jeremy H. Cc: Cynthia.Eastham@sun.com, PSARC@sac.sfbay.sun.com Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] Status: RO Jeremy, Cindy has provided a full, updated grep man page (grep.1 in the case directory). I believe it now fully explains the interactions between -H and -L with -r and -R. If this doesn't clear it up for you, Cindy will be happy to answer your questions. Further details below. Cheers, Don Jeremy H. wrote: > >Don Cragun wrote: > >> 3. Details >> The -R option enabling recursively descending through file hierarchies >> exist in many Solaris utilities, including chgrp, chown, du, ls, and cp. >> In addition, to align with SUSv3 standards, symbolic link support options, >> -H and -L, were added to these utilities. > >Add a note for "-r" too? The -r option in ggrep is a synonym for -R. Cindy is planning to duplicate that behavior in grep. The fact that -R and -r are synonyms is shown by having the two listed as shown below with a single description. > > > > >> -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. > >Do -H and -L apply with -r too? Yes. Cindy's updated man page now makes this clear. > >Should also define behaviour when -R is not specified - "otherwise, this >option is ignored"? No. The man page says what happens if you use options that are defined to work together. Since the synopsis shows that -H and -L do not have defined meaning if neither -r nor -R are specifed, the descriptions of -H and -L don't need to specify what happens in other cases. > >> >> -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. > >- Jeremy From sacadmin Wed Feb 2 18:01:58 2005 Received: from spartan.SFBay.Sun.COM (spartan [129.146.88.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j1321wSp020971 for ; Wed, 2 Feb 2005 18:01:58 -0800 (PST) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id j1320v2e018563; Wed, 2 Feb 2005 18:00:57 -0800 (PST) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10/Submit) id j1320ujx018562; Wed, 2 Feb 2005 18:00:56 -0800 (PST) Date: Wed, 2 Feb 2005 18:00:56 -0800 (PST) From: Don Cragun Message-Id: <200502030200.j1320ujx018562@spartan.SFBay.Sun.COM> To: PSARC@sac.sfbay.sun.com Cc: Cynthia.Eastham@Sun.COM Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] PSARC FastTrack [02/03/2005]: Add ggrep context and recursive search features to grep. Status: RO This case was approved by PSARC today. From sacadmin Wed Feb 2 21:35:57 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j135ZvSp002287 for ; Wed, 2 Feb 2005 21:35:57 -0800 (PST) Received: from sun.com (vpn-129-147-153-44.Central.Sun.COM [129.147.153.44]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j135Ytt8657109; Wed, 2 Feb 2005 21:34:55 -0800 (PST) Message-ID: <4201B7EE.5050002@sun.com> Date: Wed, 02 Feb 2005 21:34:38 -0800 From: Cynthia Eastham User-Agent: Mozilla Thunderbird 0.5 (X11/20040209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Cragun CC: PSARC@sac.sfbay.sun.com Subject: Re: Add ggrep context and recursive search features to grep. [PSARC/2005/049 Timeout: 02/03/2005] PSARC FastTrack [02/03/2005]: Add ggrep context and recursive search features to grep. References: <200502030200.j1320ujx018562@spartan.SFBay.Sun.COM> In-Reply-To: <200502030200.j1320ujx018562@spartan.SFBay.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Thank you SO MUCH for all of your help on this Don. You truly are amazing, and very much appreciated! Thank you, Cindy Don Cragun wrote: >This case was approved by PSARC today. > >