Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 232732 - Patch should be lenient in handling lines like '>' in patchfiles
Summary: Patch should be lenient in handling lines like '>' in patchfiles
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: patch
Version: 4.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Tim Waugh
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-16 21:24 UTC by David Tonhofer
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-17 10:24:02 UTC


Attachments (Terms of Use)

Description David Tonhofer 2007-03-16 21:24:58 UTC
Description of problem:

Application of a copy-and-pasted patch file fails:

$ patch --normal --verbose --input patch mysql_backup.sh
Hunk #1 succeeded at 15.
Hunk #2 succeeded at 109.
patch: **** `>' expected at line 35 of patch

"SOB"

Okay, the problems seems to be that a link that looks like
'>' in the patch file is considered unfriendly. It possibly
looked once like '> ' or '>\t', but copy & paste may have
mangled it.

Workaround is to manually edit the patch file and add spaces
or tabs.

A quick look at the source of patch-2.5.9 (through Google code search)
shows that the error occurs around here, though I have trouble 
extrating semantics out of this compact C style. The condition 

  (buf[0] != '>' || (buf[1] != ' ' && buf[1] != '\t'))

indicates that '> ' is acceptable while '>' is not.

It might be useful to relax this apparently fascist attitude to input.



for (i++; i<=p_end; i++) {
	    chars_read = get_line ();
	    if (chars_read == (size_t) -1)
	      {
		p_end = i - 1;
		return -1;
	      }
	    if (!chars_read)
	      fatal ("unexpected end of file in patch at line %s",
		     format_linenum (numbuf0, p_input_line));
	    if (buf[0] != '>' || (buf[1] != ' ' && buf[1] != '\t'))
	      fatal ("`>' expected at line %s of patch",
		     format_linenum (numbuf0, p_input_line));
	    chars_read -= 2 + (i == p_end && incomplete_line ());
	    p_len[i] = chars_read;
	    if (! (p_line[i] = savebuf (buf + 2, chars_read))) {
		p_end = i-1;
		return -1;
	    }
	    p_Char[i] = '+';
	}

Comment 1 Tim Waugh 2007-03-17 10:24:02 UTC
Don't copy and paste patches.  Patch is very cautious by design, and must always
alert the user to any discrepancies between the patch input and the files being
altered.

If you have a patch with word-wrapped lines or other whitespace damage,
unwrapdiff from the patchutils package may help you -- but the best advice is to
avoid damaging patches and to treat them as binary files.

Comment 2 David Tonhofer 2007-03-20 11:14:29 UTC
Ok, makes sense. 



Note You need to log in before you can comment on or make changes to this bug.