On Fri, Aug 07, 1998 at 07:03:08AM -0600, Gary L. Hennigan wrote: > Bjoern Fischer <[EMAIL PROTECTED]> 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...
