Mail Archives: cygwin/2001/12/29/19:41:24
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/
- Raw text -