Hi Brian, Brian May wrote: > While I don't feel strongly about the issue, I can't help think the > above behaviour is confusing. > > I am use to /quiet on other command line tools which enables/disables > STDOUT output. It shouldn't control both STDOUT and the Event Handler. > > The debug setting only affects the event handler, and not the log file. > While this suits my needs fine, it was unexpected. > > The logLevel parameter only affects the log file. Again, this suits > my needs, but was unexpected. > > My solution would be to have three logLevel parameters - a loglevel for > STDOUT, a loglevel for the event handler, and a log level for the log > file. So each of the logging methods can be controlled independently, > and there is no confusion as to what each one days. > > However, like I said, I don't feel too strongly about this. Well this behavior is mainly due to "historical reasons". The /quiet parameter has always been used to suppress STDOUT messages and to direct them to the event log instead. Personally I would also have said that /quiet should suppress all messages (also no writing to event log). But if I change it now I will break compatibility which makes even no logs to appear on older installation where the clients use the /quiet flag. This would require updating all existing clients. By the way this is the reason why I recomment using the parameters in config.xml and not the command-line parameters. It's simply much more easy to change later on. The current set of parameters allow you to chose: - whether you want to have debug output or not: /debug - where you want to have your output: default: STDOUT /quiet: event log So the /quiet flag is historically seen a switch to chose between STDOUT and event logging. I think in general this is absolutely fine since it allows you to chose between two different kinds of _local_ logging. There is no need to allow local output on multiple/redundant channels. Either you want to read the logs from event log or from STDOUT. It's a different story for the log files. They are usually written to a server - and therefore read by different people (sysadmins). So it makes sense to configure them completely independently. Personally (and this is what I recommend to everybody) I never use the /debug flag. It is there for compatibility reasons but the new logging feature makes it completely obsolete. So if the /debug switch is not used then it is just a matter of preference if you like to see the synchronization log on STDOUT or within the event log (chosen by the /quiet flag or setting). br, Rainer |