Hi,
On Thu, Mar 19, 2026 at 05:56:05PM +0100, Mattias Andrée wrote: > > POSIX specifies that the input shall be read from the controlling terminal, > > not from standard input, when prompting for filenames. It does not give > > any guidance for when it asks about reversing or unreversing patches, except > > that the STDIN section only refers to INPUT FILES which just says input > > files > > shall be text files — therefore reading from /dev/tty is legal and seems > > more correct. After considering this, I relaized that is true that is better to read from /dev/tty for questions, because you can have a patch in stdin and having heuristics about when to read or not from /dev/ty is worse (istty() sucks ...). I think we have a function in libutil for this now, and I think patch should use that. > > Regarding the output of the prompt, the POSIX says this should be done to > > standard output, but I though it would be better to print the prompt to the > > controlling terminals as the output may be a file. It didn't really seem > > reasonable to prompt to standard output but read from the controlling > > terminal. I don't agree here, because it means that any patch invocation even with a succesful patch would require a controlling terminal, and running patch in something like cron fail (silently or not, but it would fail). I think the standard is right here, and the correct palce for output messages is the standard output. > > > > > > + * - -N skips applied hunks rather than applied patches. > > > > I want to recall that it was just easier to implement. But I do also think > > it is more useful. The think is that thinking in hunks is much more harder than thinking in patches. For that reason I would try to keep with the POSIX behaviour > > > Why this deviation? I think patch should deal with any file in a > > > transparent > > > way. This breaks the least surprise rule. > > > > I'll investigate, but I think its just used for when it read the filename > > from the patch file, in which case I think it is correct. > > I believe this behaviour is correct. It is used when reading filenames from > the patch and when determining whether to back up a file. You do not want > to use filename like /dev/fd/3 when they appear in the file because diff > was run with a `<( )`, or even /dev/stdin. Likewise, you do not want to > attempt to back up such files. /dev/fd/3, /dev/stdin or <() are not standard things. I don't understand why we should care about this. If we care about any posible extension between the different UNIX alike systems we will not be able to write anything. > > I've used these test cases > > https://git.maandree.se/base-util-tests/tree/patch-test, > > it caught bugs in GNU patch but not in this patch. I've also been daily > > driving > > this for 10 years now without any encountering any problem. Ok. That makes sense. Could you translate them? (I am too busy :'( ). > > There are test cases for a few other utilities > > https://git.maandree.se/base-util-tests/ > > as well that could also be ported over. Interesting! I didn't know about this, but this can be very helful, we only need the man power to translate them! Regards,
