Bug 232732 - Patch should be lenient in handling lines like '>' in patchfiles
Patch should be lenient in handling lines like '>' in patchfiles
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: patch (Show other bugs)
4.0
All Linux
medium Severity low
: ---
: ---
Assigned To: Tim Waugh
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-16 17:24 EDT by David Tonhofer
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-17 06:24:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Tonhofer 2007-03-16 17:24:58 EDT
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 06:24:02 EDT
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 07:14:29 EDT
Ok, makes sense. 

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