> Hum, that's an idea. The only "negative" is that syslog does not > separate multiple executions of the program into different files. I > guess that I could put in a START and END type log information in that > case and then split the logger file based on that. Oh, and include the > PID just in case there are multiple, concurrent executions of the > program. Definately something to consider.
Both versions of the approach I mentioned provide options to automagically generate PID info and time/date stamps in the syslog entries as well. > Oh, and I know that I said "log", but I really misspoke. This is more > like a report than a log. That is, it is something that a person might > want to review or email to an end user. If you go with the PID approach, log the data in syslog, then write the PID into your unique file. You can then write a script that reads your unique file, gets the data from syslog by PID, and then formats it pretty. The getdatafromsyslog script could become a component re-used by lots of different reporting widgets. Later on, you could get syslog to write into a database table, and then the script could access that instead of the flat file. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
