Differential D30160
Enhance patch(1) to search for file being patched, from the current directory. Authored by • hselasky on May 7 2021, 1:42 PM. Tags None Referenced Files
Details
When working with code integration, it may frequently happen that directory MFC after: 1 week |diff --git a/usr.bin/patch/pch.c b/usr.bin/patch/pch.c |index 70051640cf0..94d3f24d43e 100644 |--- a/usr.bin/patch/pch.c |+++ b/usr.bin/patch/pch.c -------------------------- File to patch (enter '/' to search): / Select this file, ./test/pch.c [y]:
Diff Detail
Event TimelineComment Actions A command line argument to do this without the prompt (non-interactively) would be nice too. Comment Actions @swills : Yes, but how to avoid problem with other OS'es implementation? Do you have any suggestion for which command line arguments are free? Comment Actions May I humbly suggest -S (capitol S)? Comment Actions I never needed such thing, and cannot think about situation where it would be useful to me. That said, I believe that your file hierarchy iteration is too naive. Look at fts(3) and options it accepts, esp. about symlink following. Comment Actions I have seen the use of '**' (two asterisks) to mean "search through all directories at any depth" ... Comment Actions I'm not at all sure how I feel about this. However -S is unused in gnu patch upstream.
Comment Actions I've been using this patch for some time now on my local machine with great success. Any strong objections against this patch? @imp : You suggested using fts(3). Can we keep the code as is, simple and readable. There is a need to generate the full path for open(3), so I don't know how that will work with fts(3): Also there is no need for performance here, from my point of view.
Comment Actions To be clear, it's ok not to use fts since I don't think the code would be that much smaller (if at all). Comment Actions My gut reaction when I saw this last year was that I'm not a fan, but it is hidden behind an option, at least... I don't really have any strong objection, though it might be nice if it had slightly more intelligence to it. e.g., if I have a patch against a foo/bar/file.c, search for a file.c but if you find: x/bar/file.c and x/pineapples/file.c, prefer the former not just because it's the first discovered but because it has the most in common. FTSENT has an fts_path in addition to fts_name, so the path isn't an issue. I don't really have any strong opinion either for or against, though this feature is not something I'd likely use... Comment Actions Thanks for all your comments so far. I really appreciate it.
Comment Actions In the manual mode it will ask the user if 'path/file.xxx' is OK, so you will have the chance to select the right file or step all the possibilities. I found it useful when doing debugging. For example when getting patches from people off bugzilla, In FreeBSD all kernel files are uniqe, due to the way the kernel is linked. There cannot be two xxx.o with same xxx !
I see. Is fts protable enough to bootstrap on other OS'es?
I might just try and back it out if someone complains about it. Comment Actions I wouldn't worry about it, this is light enough and not essential for bootstrap; we could just patch it out for bootstrap versions if it came to that. Don't feel pressured to use it, though, I just find it a little easier to follow along personally.
Comment Actions I plan on submitting this soon. Please shout if you have more change requests. Thank you! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||