Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> For example exactly what is your cvommitinfo script doing, what is the > input data and what is the output you are creating with the > discrepancies you experience. > Have you tested with a really simple script so you can check what is > going on? What happened thta you thought strange? The problem is the above mentioned error message my script produces to inform the cvs user about what went wrong. It is a plain print command in Python (similar to echo, I guess) outputting a line of text and a following newline character. When called on the servers command line the script produces a Windows-Style line ending (0D 0A) which renders just as it is supposed to be. When called as commitinfo script from CVSNT the stdout output from the script is forwarded to the client. Then the CVSNT client produces wrong line endings (0D 0D 0A). ==================================================================== Using Outlook at work so getting top-post style unless doing this. But then I do not get the > markers for the existing text... Anyway, now I know what you mean and then I don't understand your concern. The extra line ending will only pollute the user feedback as double spaced messages, I think. In fact I have on one server a postcommit script that is used to keep a website up to date by doing a cvs update on the site following a commit to the module. I noticed that the feedback of the update is visible on the cvs client screen (by the user doing the commit) and with *double* spacing as compared to what one gets when one runs the command on the server itself. This might be just the same thing you are discussing. Probably CVSNT is picking up all script output to STDOUT in order to transfer it to the CVS client for display and in so doing it expands the LF to CRLF. Thus the CRLF sequence becomes CRCRLF.... If you can make your script send only LF to the STDOUT (which I doubt) then the output on the client end will probably contain only CRLF. /Bo