Sponsored Content
Top Forums Shell Programming and Scripting Parsing out the logs and generating report Post 302244493 by shellscripter on Wednesday 8th of October 2008 03:31:59 AM
Old 10-08-2008
Question Parsing out the logs and generating report

My file will contain following(log.txt):

start testcase: config loading
......
error XXXX
.....
end testcase: config loading, result failed
start testcase: ping check
.....
error ZZZZZ
.....
error AAAAA
end testcase: Ping check, result failed

I am expecting below output.
=========================================
Testcase: config loading
error XXXX
Testcase: ping check
error ZZZZ
error AAAA
==============================================

There are so many testcases like this in file also the number of error in testcase will vary.

Please give better idea using shell script. Your help will be appreciated.

Thanks
 

10 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Generating a report -Formatted printing -Urgent

Hi, My aim is to generate a report using shell script. There are various formats fields coloumns etc. I want to print in a single line (row) but in different coloumn as given below: field1 field2 field3 field4 ....... ....... ...... ....... The spacing... (1 Reply)
Discussion started by: jisha
1 Replies

2. UNIX for Dummies Questions & Answers

Parsing Powerbroker Logs for SysAdmin Changes (SOX)

I need to identify a list of AIX command strings that can be used to parse Powerbroker logs for changes that are being made by Unix SysAdmins. Need to filter out (as much as possible) inquiry or routine maintenance activity and concentrate on software/security changes. This is for internal... (1 Reply)
Discussion started by: bcouchtx
1 Replies

3. Shell Programming and Scripting

Awk Script for generating a report

Hi all, I have a log file of the below format. 20081016:000042 asdflasjdf asljfljs asdflasjf safjl 20081016:000229 /lask/ajlsdf/askdfjsa 20081016:000229 /lashflas /askdfaslj hsfhsahf 20081016:000304 lasflasj ashfashd 20081016:000304 lajfasdf ashfashdfhs I need to generate a... (3 Replies)
Discussion started by: manoj.naidu
3 Replies

4. Shell Programming and Scripting

Parsing of file for Report Generation (String parsing and splitting)

Hey guys, I have this file generated by me... i want to create some HTML output from it. The problem is that i am really confused about how do I go about reading the file. The file is in the following format: TID1 Name1 ATime=xx AResult=yyy AExpected=yyy BTime=xx BResult=yyy... (8 Replies)
Discussion started by: umar.shaikh
8 Replies

5. Shell Programming and Scripting

Parsing log files, displaying logs between specific dates

Sorry, couldn't really think of a simple subject/title. So, I have a log file, and the dates are displayed like so: 2009-03-05 02:49:44 So the first and second field are the date/time. I can change them into a unix timestamp easily with: date -d "2009-03-05 02:49:44" +%s However,... (17 Replies)
Discussion started by: Rhije
17 Replies

6. Shell Programming and Scripting

Help parsing logs maybe with menu and variables?

I would like to parse through some logs looking for things like exception or failed (grep -i failed). Ideal would be if it were in a menu format so someone without unix ability could just choose option 1 2 or 3 etc. If I could pass the hostname to a variable also that would be awesome, so someone... (5 Replies)
Discussion started by: taekwondo
5 Replies

7. UNIX and Linux Applications

Parsing Tuxedo Logs

Right now I am parsing Tuxedo logs to calculate response times for various services. I was hoping to find a log tool that had support for Tuxedo and would generate drill down html reports. ---------- Post updated at 02:35 PM ---------- Previous update was at 02:33 PM ---------- I just wanted... (0 Replies)
Discussion started by: Lurch
0 Replies

8. Shell Programming and Scripting

Generating a count report

Hi, I want to generate a report for count mismatching. Steps followed for creating a script for file in 1). I have to fetch the file name from the checksum.out #customer_information_ 2). Added Detail #customer_information_Detail 3). Check the file exist or not. 3.1.1)if the the file... (1 Reply)
Discussion started by: number10
1 Replies

9. Shell Programming and Scripting

Novice in shell scripting - generating report

Hi I recently joined a project where I have been asked to generate a report using shell script accessing UNIX box. I have no idea on how to do it as I am a beginner and learning shell scripts. Suppose I have a XML: <XYZRequest> <effectiveDate>someDate</effectiveDate>... (2 Replies)
Discussion started by: vat1kor
2 Replies

10. Shell Programming and Scripting

Comparing two files and generating the report

Hi All, What am trying to do is generate the report by compating two files. File A ----------- 111 22222 3333 222 55555 7777 File B ----------- 11A 22222 3333 333 55555 7778 Now the report should be as follows Added: 333 55555 7778 Removed: (6 Replies)
Discussion started by: Prashantckc
6 Replies
ct_hooks(3erl)						     Erlang Module Definition						    ct_hooks(3erl)

NAME
ct_hooks - A callback interface on top of Common Test DESCRIPTION
Warning: This feature is in alpha release right now. This means that the interface may change in the future and that there may be bugs. We encourage you to use this feature, but be prepared that there might be bugs and that the interface might change inbetween releases. The Common Test Hook (henceforth called CTH) framework allows extensions of the default behaviour of Common Test by means of callbacks before and after all test suite calls. It is meant for advanced users of Common Test which want to abstract out behaviour which is common to multiple test suites. In brief, Common Test Hooks allows you to: * Manipulate the runtime config before each suite configuration call * Manipulate the return of all suite configuration calls and in extension the result of the test themselves. The following sections describe the mandatory and optional CTH functions Common Test will call during test execution. For more details see Common Test Hooks in the User's Guide. For information about how to add a CTH to your suite see Installing a CTH in the User's Guide. Note: See the Example CTH in the User's Guide for a minimal example of a CTH. CALLBACK FUNCTIONS
The following functions define the callback interface for a Common Test Hook. EXPORTS
Module:init(Id, Opts) -> State Types Id = reference() | term() Opts = term() State = term() MANDATORY Always called before any other callback function. Use this to initiate any common state. It should return a state for this CTH. Id is the return value of id/1 , or a reference (created using make_ref/0 ) if id/1 is not implemented. For details about when init is called see scope in the User's Guide. Module:pre_init_per_suite(SuiteName, Config, CTHState) -> Result Types SuiteName = atom() Config = NewConfig = [{Key,Value}] CTHState = NewCTHState = term() Result = {Return, NewCTHState} Return = NewConfig | SkipOrFail SkipOrFail = {fail, Reason} | {skip, Reason} Key = atom() Value = term() Reason = term() OPTIONAL This function is called before init_per_suite if it exists. It typically contains initialization/logging which needs to be done before init_per_suite is called. If {skip,Reason} or {fail,Reason} is returned, init_per_suite and all test cases of the suite will be skipped and Reason printed in the overview log of the suite. SuiteName is the name of the suite to be run. Config is the original config list of the test suite. CTHState is the current internal state of the CTH. Return is the result of the init_per_suite function. If it is {skip,Reason} or {fail,Reason} init_per_suite will never be called, instead the initiation is considered to be skipped/failed respectively. If a NewConfig list is returned, init_per_suite will be called with that NewConfig list. See Pre Hooks in the User's Guide for more details. Note that this function is only called if the CTH has been added before init_per_suite is run, see CTH Scoping in the User's Guide for details. Module:post_init_per_suite(SuiteName, Config, Return, CTHState) -> Result Types SuiteName = atom() Config = [{Key,Value}] Return = NewReturn = Config | SkipOrFail | term() SkipOrFail = {fail, Reason} | {skip, Reason} | term() CTHState = NewCTHState = term() Result = {NewReturn, NewCTHState} Key = atom() Value = term() Reason = term() OPTIONAL This function is called after init_per_suite if it exists. It typically contains extra checks to make sure that all the correct dependencies have been started correctly. Return is what init_per_suite returned, i.e. {fail,Reason}, {skip,Reason}, a Config list or a term describing how init_per_suite failed. NewReturn is the possibly modified return value of init_per_suite . It is here possible to recover from a failure in init_per_suite by returning the ConfigList with the tc_status element removed. See Post Hooks in the User's Guide for more details. CTHState is the current internal state of the CTH. Note that this function is only called if the CTH has been added before or in init_per_suite, see CTH Scoping in the User's Guide for details. Module:pre_init_per_group(GroupName, Config, CTHState) -> Result Types GroupName = atom() Config = NewConfig = [{Key,Value}] CTHState = NewCTHState = term() Result = {NewConfig | SkipOrFail, NewCTHState} SkipOrFail = {fail,Reason} | {skip, Reason} Key = atom() Value = term() Reason = term() OPTIONAL This function is called before init_per_group if it exists. It behaves the same way as pre_init_per_suite , but for the init_per_group instead. Module:post_init_per_group(GroupName, Config, Return, CTHState) -> Result Types GroupName = atom() Config = [{Key,Value}] Return = NewReturn = Config | SkipOrFail | term() SkipOrFail = {fail,Reason} | {skip, Reason} CTHState = NewCTHState = term() Result = {NewReturn, NewCTHState} Key = atom() Value = term() Reason = term() OPTIONAL This function is called after init_per_group if it exists. It behaves the same way as post_init_per_suite , but for the init_per_group instead. Module:pre_init_per_testcase(TestcaseName, Config, CTHState) -> Result Types TestcaseName = atom() Config = NewConfig = [{Key,Value}] CTHState = NewCTHState = term() Result = {NewConfig | SkipOrFail, NewCTHState} SkipOrFail = {fail,Reason} | {skip, Reason} Key = atom() Value = term() Reason = term() OPTIONAL This function is called before init_per_testcase if it exists. It behaves the same way as pre_init_per_suite , but for the init_per_testcase function instead. Note that it is not possible to add CTH's here right now, that feature might be added later, but it would right now break backwards compatability. Module:post_end_per_testcase(TestcaseName, Config, Return, CTHState) -> Result Types TestcaseName = atom() Config = [{Key,Value}] Return = NewReturn = Config | SkipOrFail | term() SkipOrFail = {fail,Reason} | {skip, Reason} CTHState = NewCTHState = term() Result = {NewReturn, NewCTHState} Key = atom() Value = term() Reason = term() OPTIONAL This function is called after end_per_testcase if it exists. It behaves the same way as post_init_per_suite , but for the end_per_testcase function instead. Module:pre_end_per_group(GroupName, Config, CTHState) -> Result Types GroupName = atom() Config = NewConfig = [{Key,Value}] CTHState = NewCTHState = term() Result = {NewConfig | SkipOrFail, NewCTHState} SkipOrFail = {fail,Reason} | {skip, Reason} Key = atom() Value = term() Reason = term() OPTIONAL This function is called before end_per_group if it exists. It behaves the same way as pre_init_per_suite , but for the end_per_group function instead. Module:post_end_per_group(GroupName, Config, Return, CTHState) -> Result Types GroupName = atom() Config = [{Key,Value}] Return = NewReturn = Config | SkipOrFail | term() SkipOrFail = {fail,Reason} | {skip, Reason} CTHState = NewCTHState = term() Result = {NewReturn, NewCTHState} Key = atom() Value = term() Reason = term() OPTIONAL This function is called after end_per_group if it exists. It behaves the same way as post_init_per_suite , but for the end_per_group function instead. Module:pre_end_per_suite(SuiteName, Config, CTHState) -> Result Types SuiteName = atom() Config = NewConfig = [{Key,Value}] CTHState = NewCTHState = term() Result = {NewConfig | SkipOrFail, NewCTHState} SkipOrFail = {fail,Reason} | {skip, Reason} Key = atom() Value = term() Reason = term() OPTIONAL This function is called before end_per_suite if it exists. It behaves the same way as pre_init_per_suite , but for the end_per_suite function instead. Module:post_end_per_suite(SuiteName, Config, Return, CTHState) -> Result Types SuiteName = atom() Config = [{Key,Value}] Return = NewReturn = Config | SkipOrFail | term() SkipOrFail = {fail,Reason} | {skip, Reason} CTHState = NewCTHState = term() Result = {NewReturn, NewCTHState} Key = atom() Value = term() Reason = term() OPTIONAL This function is called after end_per_suite if it exists. It behaves the same way as post_init_per_suite , but for the end_per_suite function instead. Module:on_tc_fail(TestcaseName, Reason, CTHState) -> NewCTHState Types TestcaseName = init_per_suite | end_per_suite | init_per_group | end_per_group | atom() Reason = term() CTHState = NewCTHState = term() OPTIONAL This function is called whenever a testcase fails. It is called after the post function has been called for the testcase which failed. i.e. if init_per_suite fails this function is called after post_init_per_suite , and if a testcase fails it is called after post_end_per_testcase . The data which comes with the Reason follows the same format as the FailReason in the tc_done event. See Event Handling in the User's Guide for details. Module:on_tc_skip(TestcaseName, Reason, CTHState) -> NewCTHState Types TestcaseName = end_per_suite | init_per_group | end_per_group | atom() Reason = {tc_auto_skip | tc_user_skip, term()} CTHState = NewCTHState = term() OPTIONAL This function is called whenever a testcase is skipped. It is called after the post function has been called for the testcase which was skipped. i.e. if init_per_group is skipped this function is called after post_init_per_group , and if a testcase is skipped it is called after post_end_per_testcase . The data which comes with the Reason follows the same format as tc_auto_skip and tc_user_skip events. See Event Handling in the User's Guide for details. Module:terminate(CTHState) Types CTHState = term() OPTIONAL This function is called at the end of a CTH's scope . Module:id(Opts) -> Id Types Opts = term() Id = term() OPTIONAL The Id is used to uniquely identify a CTH instance, if two CTH's return the same Id the second CTH is ignored and subsequent calls to the CTH will only be made to the first instance. For more information see Installing a CTH in the User's Guide. This function should NOT have any side effects as it might be called multiple times by Common Test. If not implemented the CTH will act as if this function returned a call to make_ref/0 . Ericsson AB common_test 1.5.3 ct_hooks(3erl)
All times are GMT -4. The time now is 05:37 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy