RE: ** UNIX shell -- grep behavior different

From: A Joshi <>
Date: Sun, 28 Nov 2010 20:51:37 -0800 (PST)
Message-ID: <>

here is what I did
created another shell script to just do the

grep -i created $flist
grep -i created $flist > $mlist


it worked fine. there were 14 'created' lines in both $flist $mlist . all okay. So looks like it was some issue with $flist not getting closed or something like that.

so now I have separated the Main shell script into two parts. two different shell scripts

script one

. /opt/oracle/scripts/setenv
cd /opt/oracle/scripts

mlist=/opt/oracle/scripts/mail_new_obj.log echo ' '> $flist
echo ' '> $mlist

cat $DBS | while read DB
sqlplus db_ro_at_$DB @new_objects.sql <.pw >> $flist done

script two
. /opt/oracle/scripts/setenv
cd /opt/oracle/scripts


grep -i created $flist > $mlist


Main script calls these two in order .everything is fine now.

  • On Sun, 11/28/10, A Joshi <> wrote:

From: A Joshi <>
Subject: RE: ** UNIX shell -- grep behavior different To:
Date: Sunday, November 28, 2010, 3:27 PM


I added set -v but it is not giving any additional information which grep from both shell script, UNIX interactive session gives same output /bin/grep

+ which grep
I also hardcoded /bin/grep
but still it is same behavior
 the first. is to set the environment. I'm using the same for interactive session. I plan to expand this for other database info to be checked every day/week. cat /opt/oracle/scripts/dbs
right now I'm just going to copy another existing shell script with different steps and make changes and see if that works.instead of struggling with this. --- On Sat, 11/27/10, Mark W. Farnham <> wrote:

From: Mark W. Farnham <>
Subject: RE: ** UNIX shell -- grep behavior different To:, Cc:, Date: Saturday, November 27, 2010, 1:43 PM

The contents of the file you’re dotting right at the top and echoing the path and arguments might also be useful in debugging this.  
Writing a “hello world” harness and just always using that as your wrapper is probably useful in the long haul for things that actually need to be done with scripts.  
Differences in the processing of certain escape characters between the interactive shell \(  \) are possible depending on the shell, but the aforementioned different path seems more probable; adding a whence (or which) grep might also be useful.  
OR, since you have database software, create a DBA datawarehouse, make a table and insert into it from all the databases you’re monitoring. Then just write a select. Parsing stuff in scripts is fine when you need to, but why bother when the database would be a good place to stash your data so you can slice and dice it arbitrarily in the future.  
For the purpose you’re after, Rightsizing, Inc. marketed something called EXTMON in the mid 1990’s, that tracks creation and extension of all the objects in a database. Since it was a clear text set of scripts, people generally ignored the copywrite and we stopped keeping it current. You can probably find it or a copy out there somewhere. You’ll probably have to change a few things to make it worth comprehensively for 11g.  
Several of our clients used reports off that history to plan capital acquisition of disk space.  

From: [] On Behalf Of Jared Still Sent: Saturday, November 27, 2010 1:20 PM To:
Cc:; Subject: Re: ** UNIX shell -- grep behavior different  

On Fri, Nov 26, 2010 at 7:17 PM, A Joshi <> wrote:


set -x


you might try adding set -v here for troubleshooting purposes


grep -i created $flist
grep -i created $flist > $mlist


If you run the script, then run the grep from the command line against this

file ($mlist), the grep finds all the values you expect?


To paraphrase Inigo Montoya "I don't think you're using the grep you think you're using"


Try hardcoding the full path for grep, which is usually a good idea in shell scripts anyway.


Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist Oracle Blog: Home Page:


Received on Sun Nov 28 2010 - 22:51:37 CST

Original text of this message