RE: ** UNIX shell -- grep behavior different
- From: A Joshi <ajoshi977@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Sun, 28 Nov 2010 12:27:33 -0800 (PST)
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
Other related posts:
