bugGNU patch - Bugs: bug #25934, Comments trip up patch

 
 

bug #25934: Comments trip up patch

Submitted by:  Andreas Gruenbacher <agruen>
Submitted on:  Fri 20 Mar 2009 03:24:25 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Andreas Gruenbacher <agruen>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sun 22 Mar 2009 09:44:44 PM UTC, comment #7:

I have changed things so that now, when no filename was specified on the command line and when conforming to POSIX, patch will still detect patches without filename headers and ask for a filename.

Andreas Gruenbacher <agruen>
Project AdministratorIn charge of this item.
Sun 22 Mar 2009 09:42:05 PM UTC, comment #6:

I have changed things so that when no filename was specified

patch will only ask about the filename when

patches without filename

Andreas Gruenbacher <agruen>
Project AdministratorIn charge of this item.
Sun 22 Mar 2009 09:05:23 PM UTC, comment #5:

Unfortunately, POSIX specifies that if a file contains more than one patch, it must process each of those patches as if they came form individual files. If a patch is found but no name, it must ask the user as a last resort. The strategy of only checking for lines containing file names until a name has been found conflicts with this requirement.

POSIX also requires support for indented patches, so this also cannot be made optional.

Tightening up the check for normal format commands alone fixes this specific case, but enough text is recognized as commands for this bug to pop up again in the future.

Andreas Gruenbacher <agruen>
Project AdministratorIn charge of this item.
Sun 22 Mar 2009 05:55:23 AM UTC, comment #4:

Fixed in two ways:

  • unless a filename has been specified on the command line,

look only for filenames in the patch until one is found
before looking for hunks.

  • Be more strict in recognizing normal format commands. Check

for trailing garbage after commands.

Andreas Gruenbacher <agruen>
Project AdministratorIn charge of this item.
Sun 22 Mar 2009 03:11:24 AM UTC, comment #3:

The test case in comment 0 does not trigger the bug, but this one does -- the isolated dot (which occurs in the original patch) matters:

--------------------- 8< ---------------------
New driver for the Amiga 4000T built-in
NCR53c710 SCSI controller, using the
53c700 SCSI core.
.
--------------------- 8< ---------------------

Andreas Gruenbacher <agruen>
Project AdministratorIn charge of this item.
Fri 20 Mar 2009 05:27:30 AM UTC, comment #2:

> To remain back-compatible, add a new command line option
> which suppresses all the automagic detection stuff.


Nobody would use that option. (Like people usually don't apply patches with -u.)

Andreas Gruenbacher <agruen>
Project AdministratorIn charge of this item.
Fri 20 Mar 2009 05:22:32 AM UTC, comment #1:

>Can we get rid of trying to recognize indented patches (at least
> for the ed format, but preferably for all formats)?


To remain back-compatible, add a new command line option which
suppresses all the automagic detection stuff.

Anonymous
Fri 20 Mar 2009 03:24:25 AM UTC, original submission:

When a patch file is read, patch tries to guess the format and locate the beginning of a patch. When people include comments before the patch, this sometimes causes patch to take a comment for the beginning of a patch. (This is made much worse because patch also tries to recognize indented patches.)

For example, in this comment, patch things that 53c700 is an ed command:

--------------------- 8< ---------------------
New driver for the Amiga 4000T built-in
NCR53c710 SCSI controller, using the
53c700 SCSI core.
--------------------- 8< ---------------------

Explicitly providing the `-u' arg prevents that.

(Reported by Andrew Morton <akpm@linux-foundation.org>)

Can we get rid of trying to recognize indented patches (at least for the ed format, but preferably for all formats)?

Andreas Gruenbacher <agruen>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by agruen (Submitted the item)
  • -unavailable- added by agruen
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 06 Apr 2009 03:02:23 PM UTCagruenStatusIn Progress=>Fixed
      Open/ClosedOpen=>Closed
    Sun 22 Mar 2009 09:05:23 PM UTCagruenStatusFixed=>In Progress
      Open/ClosedClosed=>Open
    Sun 22 Mar 2009 05:55:23 AM UTCagruenStatusNone=>Fixed
      Assigned toNone=>agruen
      Open/ClosedOpen=>Closed
    Fri 20 Mar 2009 03:24:25 AM UTCagruenCarbon-Copy-=>Added andrew morton

    Back to the top


    Powered by Savane 3.1-cleanup1