Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3C2E62BD.62E6C3B1@california.com> Date: Sat, 29 Dec 2001 16:41:33 -0800 From: wi X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: setup for cvs client to strip carriage returns Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Quick questions, explanations follow: - Exactly what happens when setup.exe sets "default text file type" to unix? - Does reinstalling with a different setting change the effect completely? - Can I get cygwin cvs to remove and add \r on upload\download by using mount to tag my local repository as text mode? I'm trying to debug - why my files are checked into cvs with ^M (\r) and how to avoid this in the future - what I need to do to clean up the situation if some of the files in the global repository have \r (in particular: do I need to check any affected files in correctly, or can I rely on the next checkin to clean up the problem?) I've looked through faq/docs/email (relevant links below) but have not found a complete answer. My model of the correct behavior doesn't seem to track reality :). I'd prefer (in order): a) the cvs server to strip any incoming \r\n to \n, leaving it to DOS cvs clients to prefix \r to \n (or tell server to); or b) the cvs client to strip/add as needed, or c) the local editor, diff, etc. to ignore \r and not add on write. But... a) is for gnu/cvshome.org to answer c) is a royal pain (er, I mean it's a support problem) b) seems to be how it's handled, though not consistently. As I understand it, instead of having the cvs server enforce the stripping of \r\n to \n,[1] it's left to the windows-based cvs clients. I think the right thing is always to add/strip \r\n combinations, but I'm hearing that the cygwin cvs client is instead trying to operate in binary mode (and hence preserve the \r\n?)[2]. Is that right? This problem might be more prevalent than reported if/since editors are masking it by handling the adding/stripping themselves and it only shows up where users operate on the same files from windows and unix. It might only show up as cvs diff's (i.e., sans -b flag) reporting excess changes.[3] I'd like the cvs client to manage the \r\n as follows [4]: (a) prefix \r to \n in files when downloaded to local repository from global repository, only if \r is not already a prefix, (b) remove \r prefix from \r\n in files when uploaded to global repository from local, including all \r before \n. That would mean a windows cvs client would work when the local repository is either windows or unix-based. The alternative of preserving the \r essentially make the files less usable on unix (file-)systems. I thought that was how it worked, but I have no basis for this except hearsay. I think that would track user expectations. Before reading that the cvs client uses binary mode, I thought I could force this behavior by setting the mount point of the local repository to text mode (or having the repository on an unmounted path), because of the way that \r is handled by cygwin. - filtering for \r during file-read and file-write is handled on a per-application basis according to these rules: - a file will be filtered if it is opened in text mode - a file will be opened in text mode if any of the following are true: - the file system call (via cygwin) specifies text mode - the file is marked as a text file (how?) - the file is not marked as binary mode, and - the mount point is marked for text mode (using the mount command), or - the path is not associated with a mount point, and so enjoys the default behavior, which is text; unless - CYGWIN variable is set up to default to binary mode (binmode) So now you understand the basis for my questions. I'm concerned that "unix mode" means "binary" is the default mode for all files, and I'm not sure that updating the CYGWIN variable would help there (or where the various settings are stored - .profile?) I'm also concerned that the binary read/write is not overridable via mount-modes because the cvs client was written using binary flags in the file IO calls. Lastly, I'd prefer this behavior to be the default and/or explicitly specifiable rather than inferred from settings which may be legitimate for other reasons. Thanks for plowing through a long post, and (in advance) for any help. Wes [1] I'd prefer the cvs server to enforce this (on request), to avoid depending on every windows cvs client to be implemented correctly, or requiring every client (e.g., on Linux) handle windows linefeeds. [2] http://cygwin.com/ml/cygwin/2001-12/msg01277.html [3] http://cygwin.com/ml/cygwin/2001-12/msg01089.html [4] This behavior might be conditioned on the "unix mode" flag not being set (i.e., no need) or the local repository files not being in binary mode (marked, binary mount, or CYGWIN variable). However, I'd much prefer an explicit cvs client flag or environment variable to these, since there are good reasons to set those modes unrelated to cvs behavior. ------------------------ references - cygwin handles \r re-writing when using text mode http://cygwin.com/cygwin-ug-net/using-textbinary.html - use mount to force binmode http://cygwin.com/ml/cygwin/2001-12/msg01146.html http://cygwin.com/cygwin-ug-net/using.html#MOUNT-TABLE - binmode works for cvs (but to _preserve_ \r?) http://cygwin.com/ml/cygwin/2001-12/msg01137.html - mount mode take precedence over CYGWIN variable setting http://cygwin.com/ml/cygwin/2001-12/msg01146.html - cvs developer may have not specified binary mode on some cvs file call - asking for test help, and concerned about forcing binary mode on text mode users http://cygwin.com/ml/cygwin/2001-12/msg01277.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/