This is the mail archive of the
mailing list for the Cygwin project.
Re: New versions of bzip2 and patch?
On Tue, Nov 21, 2000 at 03:02:39AM +0100, Michael Ring wrote:
>> --- Michael Ring <email@example.com> 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
>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.
I don't think this is the correct solution. You're removing
functionality from patch which people could potentially rely upon. The
correct solution, IMO, is to use either automode.o or textmode.o (if we
decide that we aren't doing binary patching) or to modify the fopen/open
calls to specifically open the files in the correct mode (text or
>>>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
What is your example? The example of producing lf style line endings,
i.e., doing what automode.o was designed to do? The only thing I'm
aware of that this will break is something like 'notepad'.
FWIW, I just used this in my recent (unannounced) bison update.
(Now watch, and there will be at least one bison error report tomorrow)
>>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
>No need for this I think, simply do not link with automode and
>everything is fine ;-)
Except it isn't. You are apparently defaulting to the use of /tmp,
correct? I don't see how that solves anything since the directory that
you're currently in could have a different mount mode than /tmp.