Mailing-List:	contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe:	<mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-apps/>
List-Post:	<mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To:	mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID:	<3A19D7BF.577236B9@t-online.de>
Date:	Tue, 21 Nov 2000 03:02:39 +0100
From:	michael-ring AT t-online DOT de (Michael Ring)
X-Mailer:	Mozilla 4.75 [de] (Windows NT 5.0; U)
X-Accept-Language:	de
MIME-Version:	1.0
To:	cygwin-apps AT sources DOT redhat DOT com
Subject:	Re: New versions of bzip2 and patch?
References:	<20001121014021 DOT 4252 DOT qmail AT web123 DOT yahoomail DOT com>
X-Sender:	320032306730-0001 AT t-dialin DOT net

> 
> --- Michael Ring <michael-ring AT t-online DOT de> wrote:
> > I only removed a stupid (imho) usage of environment-variables from patch
> > which caused it to convert textfiles in binmounts to cr/lf files.
> > automode.o sounds as if it were useable for patch but right now I think
> > it should be kept as it is because it has prooven to work 'as is'.
> >
> 
> Patch is currently working correctly now, AFAICT.  Are there any know reasons
> to apply patches to patch?
> 

Original patch uses TEMP,TMP amd TMPDIR env-vars. If you are using
binmode for / and deeper directories and do not modify TMP or TEMP and
then you are in trouble.

Say you have a unix-file in /tmp and a patch file for it in /tmp too. 
original patch takes the file, applies the patches and stores the result
in $TEMP (or TMP or TMPDIR) before doing the final copy to the resulting
patched file.

In a standard installation TMP or TEMP points to a directory outside
your cygwin installation (normally somewhere on the drive where nt is
installed). The drive is accessed in textmode per default, so the
temporary files gets written with cr/lf endings. The final copy now puts
this cr/lf file in your /tmp directory and now you end up with a file
that includes cr/lf (which is not what you want).

I have seen postings about this problem every once a while on cygwin.

> > Hmm... thinking about it agauin, what about this theory:
> >
> > If I understand automode correctly a file on a textmount would be
> > converted to a 'unix'-style file internally and if saved in binmode
> > there would be no more cr/lf in the file; theory right ???
> >
> 
> Which in itself could present problems.  Let's see, diff file is on text mount
> with \r\n line endings, and source is on a binary mount with \n line endings.
> Will not cause a problem currently or with automode.  If diff file is on binary
> mount with \r\n line endings and source is on binary mount with \n line
> endings.  Automode would correct this problem, while currently you would end up
> with being unable to patch the file.  With diff file on binary mount and \r\n
> line endings and source on text mount with \n line endings, currently the file
> would patch and give you \r\n line endings in source while with automode you
> would get \n line endings in the result.
> 

To me, automode does not seem to make much sense because it can only be
used in a small amount of cases and some cases exist where it does do
harm. (my example, for example). I do not think that one should put
automode in any tool because it would make the tool unuseable on
text-only mounts.

> Ok, automode would solve a problem with text files.  Does anyone use patch to
> patch a binary file?  If so then --binary would need to be enabled for Cygwin,
> which based on patch --help comments it isn't currently.
> 

No need for this I think, simply do not link with automode and
everything is fine ;-)


> Cheers,
> 
> =====
> Earnie Boyd
> mailto:earnie_boyd AT yahoo DOT com
> 

Michael Ring

- Raw text -