Jared 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 /bin/grep I also hardcoded /bin/grep but still it is same behavior Mark 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 DBST1 DBST4 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 <mwf@xxxxxxxx> wrote: From: Mark W. Farnham <mwf@xxxxxxxx> Subject: RE: ** UNIX shell -- grep behavior different To: jkstill@xxxxxxxxx, ajoshi97@xxxxxxxxx Cc: rajendra.pande@xxxxxxx, oracle-l@xxxxxxxxxxxxx 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. mwf From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jared Still Sent: Saturday, November 27, 2010 1:20 PM To: ajoshi97@xxxxxxxxx Cc: rajendra.pande@xxxxxxx; oracle-l@xxxxxxxxxxxxx Subject: Re: ** UNIX shell -- grep behavior different On Fri, Nov 26, 2010 at 7:17 PM, A Joshi <ajoshi977@xxxxxxxxx> 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: http://jkstill.blogspot.com Home Page: http://jaredstill.com