Re: cvs abusing stderr?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: but I am sure that it can read from cvs' stdout instead of stderr, too. Yes, it *could*. But at the moment it expects this particular input from stderr and all (?) other versions of CVS servers send it at stderr. There are already too much differences between GNU CVS and CVSNT... Wouldn't it be more consistent to reserve stderr for error messages, and to write log messages to stdout, as usual? It would be more consistent, if the client-server protocol (and this is what we are talking about) would send the information in a unambiguous format and translate it *at client side* in human readable text. Unfortunately, the CVS server already converts it to human readable format and the more advanced clients need to parse it, which is not possible correctly in all cases (e.g. imagine file names with spaces and the output of the 'cvs history' command). Hrm. What about using GNU gettext and tweaking the MT responses to transmit messages as GNU gettext message keys and values to sub? The gettext hooks are already in the feature release of CVS but it would be a lot of work. MT should adapt pretty well since the client/server protocol contract already states that MT stuff can be printed as is if the client doesn't understand, though temporarily it might shuffle some output away from stderr. For example: MT +error MT gettext This is an error message about a problem with MT filename path/to/file.c MT gettext on MT datetime 2005-04-29 17:18 - MT gettext . Do something about it. MT newline MT -error Could be either printed verbatim, in legible english, by a client, or converted to a call to gettext like: gettext (This is an error message about a problem with %1 on %2. Do something about it., var1, var2); Or, at least I think so. I'm not sure how easy it is to dynamically construct the gettext key, but I imagine someone must have run up against a problem like this already. A gettext conversion has been on my nice to see list for awhile now anyhow. It would be nice to see a complete patch. This all reminds me, I've been idly considering the advantages of importing either the lightweight Expat XML parsing library or Gnome's lightweight libxml and moving, eventually, to an XML format for configuration files, trigger script input (since under the current scheme, info passed to the trigger scripts are limited to whatever environment limits are inherited from the shell, often 4096 bytes, I think...). XML would be simpler, more consistent, more extensible, and would solve a lot of existing problems involving spaces in file names and whatnot, possibly even unicode characters in paths. I was also idly wondering about converting the client/server protocol as well, though I don't know much about what it means to have a two-way protocol using XML. Perhaps XMLRPC or the like would provide a clue? Anyhow, I wasn't planning on doing any of this anytime soon, I just thought it might be useful to see what sort of early discussions I could start on the subjects. Regards, Derek -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCcm5vLD1OTBfyMaQRAsmbAJ9/LQzfMX8cIG3gUFWL+x6kRI7NzQCgtRi4 Ndx5o1q+X+O/8ORWdjKCm/w= =TPqr -END PGP SIGNATURE- ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs abusing stderr?
[EMAIL PROTECTED] wrote: Just to prevent an out-of-the-brain change: if they would we sent to stdout, this would break at least SmartCVS. I don't want to break your GUI, but I am sure that it can read from cvs' stdout instead of stderr, too. Wouldn't it be more consistent to reserve stderr for error messages, and to write log messages to stdout, as usual? Regards Harri ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs abusing stderr?
but I am sure that it can read from cvs' stdout instead of stderr, too. Yes, it *could*. But at the moment it expects this particular input from stderr and all (?) other versions of CVS servers send it at stderr. There are already too much differences between GNU CVS and CVSNT... Wouldn't it be more consistent to reserve stderr for error messages, and to write log messages to stdout, as usual? It would be more consistent, if the client-server protocol (and this is what we are talking about) would send the information in a unambiguous format and translate it *at client side* in human readable text. Unfortunately, the CVS server already converts it to human readable format and the more advanced clients need to parse it, which is not possible correctly in all cases (e.g. imagine file names with spaces and the output of the 'cvs history' command). -- Best regards Thomas Singer _ smartcvs.com Harald Dunkel wrote: [EMAIL PROTECTED] wrote: Just to prevent an out-of-the-brain change: if they would we sent to stdout, this would break at least SmartCVS. I don't want to break your GUI, but I am sure that it can read from cvs' stdout instead of stderr, too. Wouldn't it be more consistent to reserve stderr for error messages, and to write log messages to stdout, as usual? Regards Harri ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
cvs abusing stderr?
Hi folks, Any special reason why cvs prints a list of cvs server: Updating modulename on stderr instead of stdout? This is surely just a log message, which is supposed to be printed on stdout. On a huge project the _real_ error messages are hidden between all the garbage. It would be nice if this could be fixed. Many thanx Harri ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: cvs abusing stderr?
Harald Dunkel wrote: Any special reason why cvs prints a list of cvs server: Updating modulename on stderr instead of stdout? This is surely just a log message, which is supposed to be printed on stdout. On a huge project the _real_ error messages are hidden between all the garbage. It would be nice if this could be fixed. I can't comment on why these messages go to stderr instead of stdout, but I will mention that the global -q flag suppresses them. I use '-q' so much it's in my .cvsrc file ;-) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs abusing stderr?
Jim.Hyslop wrote: I can't comment on why these messages go to stderr instead of stdout, but I will mention that the global -q flag suppresses them. I use '-q' so much it's in my .cvsrc file ;-) I have seen -q and -Q, but I don't want to suppress these messages completely. They should just not go to stderr. Regards Harri ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs abusing stderr?
Just to prevent an out-of-the-brain change: if they would we sent to stdout, this would break at least SmartCVS. -- Best regards, Thomas Singer _ smartcvs.com Harald Dunkel schrieb: Jim.Hyslop wrote: I can't comment on why these messages go to stderr instead of stdout, but I will mention that the global -q flag suppresses them. I use '-q' so much it's in my .cvsrc file ;-) I have seen -q and -Q, but I don't want to suppress these messages completely. They should just not go to stderr. Regards Harri ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
