Add a New Comment Rich Markup
It's an interesting idea, though I am not sure if this is a good way to divide the output. The patch command already uses stderr for problems internal to the program itself. In other words stderr shows the status of patch itself while stdout displays information regarding the files being worked on. If problems with the files being worked on are moved to stderr then they will mix with patch's own internal warnings while only "good" reports will print to stdout. That seems more messy rather than less, in my opinion. This seems like a situation where output should be filtered and divided by existing UNIX utilities rather than by the program itself. Something like "patch -p2 < my.diff | tee all.log | grep FAIL > bad.log" Follow-up thoughts? Opinions?
Cf. http://bugs.debian.org/541855 Package: patch Version: 2.5.9-5 Severity: minor It would be helpful if failure messages were displayed on stderr, not stdout to filter the messages Hunk #5 FAILED at 220. 1 out of 6 hunks FAILED -- saving rejects to file arch/sh/kernel/time_32.c.rej An example: patch -p2 < *.diff > good.log 2> bad.log
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only logged-in users can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.12