This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch and Cygwin

Eli Zaretskii wrote:

What's wrong with the patched file having CRLF on Windows?

It is the default line endings on Windows so normally that is what you want. However if you have a file with LF line endings instead then don't you probably have that for a reason? I can of course not know the reason, but I guess there is some.

I am not for example convinced that all cvs implementations on Windows can handle that a checked out file has got changed line end format. In fact I believe I have read that they can not, but I am not sure here either. In any case it seems better to try to avoid problems.

But why should I care about these strange combinations on Windows?
Why isn't it enough that patching Unix-style files with Unix-style
patch files works (using --binary) and preserves the EOL type, and
patching DOS-style files with DOS-style patch files also works?

I do not know if you should care, but I do. It just happened to me that things did not work because of one of these other non-working combinations did occur for me. I did not first understand what happened. I thought that maybe the file to patch had changed and not until I got a message from others that the patch worked for them did I think of the problem with CR-LF/LF. (The patch file to my surprise had LF endings. In my opinion this should not have happened. I got a bit fooled by Emacs here.)

Now these surprising situations may take a lot of time when you got into them. Especially for someone not used to them. As you surely know I am trying to get more people on Windows to use Emacs and my interest in patch and Cygwin comes out of this. Those people I think of are Windows users. Maybe they have a long background in computers, but that does not help very much when there is too many things that just does not work out-of-the-box.

Why the perfectionism? If the usual cases work so well, why do we
want to insist on looking for trouble at all costs?

I hope it is not perfectionism. If you like me do many different things with a computer you are likely to get into cases like those I have as test cases. I can hardly touch a computer without finding something that does not work on it ;-)

Because I can find no other explanation for the fact that the test
that failed for you worked for me. Maybe you should try installing
all the utilities again, make sure what Diff and what Patch runs in
each command, and see whether gnuwin32-test.cmd indeed fails for you.

Could we be misunderstanding each other? Which test case worked for you but failed for me?

I didn't run the shell scripts because
there's no GnuWin32 port of Bash, and because I didn't want to mix the
Diff/Patch issue with the shell behavior. just reads the output from the test and presents that in a condensed manner. It could be run from most shells I believe (but the test for ^M is perhaps a bit weak ...)

That will not be easy using the techniques you tried in sh-tests, I
suspect. Perhaps "od -c" is a good start.

You are right, I will try something else.

Thanks for the answers.

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]