Re: patch 2.5-2 problem
On Fri, Aug 07, 1998 at 07:03:08AM -0600, Gary L. Hennigan wrote:
> Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE> writes:
> | while setting up a small network from scratch with hamm, I found that
> | /usr/bin/patch ( patch_2.5-2 ) fails to locate files in directories
> | deeper than one (eg. *** drivers/sound/lowlevel/init.c ). When patch
> | prompts for an alternative file name I exactly give `drivers/sound/lo
> | wlevel/init.c' -- and it worx. ( options like -d or -p are set
> | properly. )
>
> How and where are you running patch and what do the file
> specifications in the patch file look like? Basically you ALWAYS have
> to give the "-p" option to patch. Even, if you're applying the patch
> from the base directory of the patch file you have to give it the -p0
> option, although there are recommendations to go into the root
> directory first and use -p1 (see note at the end).
>
[...]
> I've used it for at least a directory depth of 4 so I know it
> works. If using the -p0 argument doesn't do what you want, and the
> note below doesn't help, post a small example patch and how you're
> trying to invoke patch and maybe we can help further.
Oops, blame on me. Should have RTFM. You're completely right with that
-p stuff. The man page for patch describes this behavior: with -p0
full path and w/o any -p basename only. So it's not a bug -- it's a
feature. But what's it for? The former patch in Debian `bo' behaved
differently. Interesting to know if it's for some POSIX/Unix98
compatibility...
...I'm also thinking of the `ps' in hamm: No SysV/POSIX(?) style
options any more :-(
Bjorn
PS: I've been used to skip RTFM and directly start RTFS due to
obsolete man pages. Maybe on Debian this will be different...
Reply to: