Chris Hallman wrote:
> 
> Thanks for all the input!!! I really appreciate it. I need to post a 
> correction to my script. What I sent was an early version. I made a few 
> minor modifications:

You don't seem to have incorporated any of the suggestions that you have 
received!

I doubt that a 4000-line ini file will be any problem at all.

Kent

> 
> import ConfigParser, string, sys, os
> section = sys.argv[1]
> interface = sys.argv[3]
> INI=ConfigParser.ConfigParser()
> INI.read("c:\utils\interfaces.ini")
> interface_entries=[p for p in INI.options
> (section)]
> interface_list=[INI.get(section, pw) for pw in interface_entries]
> for i in interface_list:
>       if i == interface:
>               os.system("d:\\tnd\\bin\\cawto.exe -cat NetNet -n l17aesm1 
> forward red held " + 
> sys.argv[1] + " " + sys.argv[2] + " " + sys.argv[3] + " " + sys.argv[4])
> 
> 
> I've researched what you all have suggested and I may need to switch to 
> reading the ini file line by line or using a different file parser. The 
> ini file is only 100 lines long now, but will likely grow to 500 line 
> and maybe to 4000 lines. To give you a better background of what I'm 
> doing with this script, it's running on a network management system that 
> receives traps. After some processing of the raw trap, messages get sent 
> to this script for further processing. These messages are for interface 
> down traps from routers and switches in our network. I use this script 
> to mitigate the number of interface down messages on our console. I need 
> to do this because we do not need to know when every port has gone down 
> (i.e. user ports). This script searches the ini file for a device name 
> match. Once it has found a match and if the interface matches as well, I 
> need to message forwarded to the console (the Windows command). If no 
> matching device or interface is found, then the script can just exit.
> 
> 
> On 9/26/05, *Kent Johnson* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 
> wrote:
> 
>     Kent Johnson wrote:
>      > *TEST FIRST* Don't optimize until you know it is too slow and you
>      > have a test case that you can time to see if your 'optimizations' are
>      > making it faster.
> 
>     Pardon my shouting :-)
> 
>     Kent
> 
>     _______________________________________________
>     Tutor maillist  -  Tutor@python.org <mailto:Tutor@python.org>
>     http://mail.python.org/mailman/listinfo/tutor
>     <http://mail.python.org/mailman/listinfo/tutor>
> 
> 

_______________________________________________
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Reply via email to