Mail Archives: cygwin/2001/03/07/17:08:14
On Wed, Mar 07, 2001 at 01:29:23PM -0800, David Rees wrote:
>On Wed, 7 Mar 2001 11:15:25 -0500, Christopher Faylor wrote:
>>On Wed, Mar 07, 2001 at 12:19:29AM -0800, David Rees wrote:
>>>Also, as I hope I implied (but didn't say) in my previous email,
>>>altering the diff file to use backward slashes as follows also causes
>>>patch to run fine:
>>>|--- src\testcases\org\apache\tools\ant\taskdefs\ZipTest.java 2001/03/02 16:01:01 1.3
>>>|+++ src\testcases\org\apache\tools\ant\taskdefs\ZipTest.java 2001/03/07 00:11:39
>>
>>Yeah, you've changed the paths into a format that patch doesn't really
>>understand, so it just applies the patch to the current directory.
>>Patch has no idea that '\' is a directory separator. On Unix, it's a
>>valid filename character. However, when this "filename" reaches the
>>Windows API layour, Windows will translate it into a relative path so
>>things will "work".
>
>Your explanation makes sense, but shouldn't it be using the cygwin DLL
>to recognize that its directory path? Its obviously using the cygwin
>DLL to access the file.
Cygwin uses the Windows API to do everything. Cygwin doesn't go out of
its way to disallow Windows paths. When patch passed the backslashed
file to cygwin, it happily passed it along to the correct Windows function
bypassing any translation to a "UNIX-like" path.
>>>All this said, using "-p0" or "-p" solves the problem. However, from
>>>my understanding, patch should do -p0 by default since its a relative
>>>directory. So what I think seems to be happening is that patch doesn't
>>>recognize a relative path inside a patch file as relative if it uses
>>>forward slashes.
>>
>>Your understanding is incorrect. Patch does not default to -p0 by
>>default. Not supplying -pN on the command line is a common cockpit
>>error when attempting to apply a patch. There is nothing strange going
>>on here besides the fact that you didn't supply -p0 on the command
>>line.
>>
>
>This is from the diffutils manual:
>"By default, patch strips off all leading directories, leaving just
>the base file names, except that when a file name given in the patch
>is a relative file name and all of its leading directories already
>exist, patch does not strip off the leading directory. (A relative
>file name is one that does not start with a slash.) "
>
>http://www.delorie.com/gnu/docs/diffutils/diff_77.html
>
>Of course, the patch manual doesn't mention what it does for relative
>vs. absolute files at all.
>
>Maybe its a version issue? Anyway, the obvious solution is always use
>-p0.
I don't think so. I have never seen patch behave in this fashion. It
doesn't work this way on Linux, AFAICT.
I think it's a documentation glitch.
cgf
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -