A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1872 
====================================================================== 
Reported By:                steffen
Assigned To:                
====================================================================== 
Project:                    1003.1(2024)/Issue8
Issue ID:                   1872
Category:                   Shell and Utilities
Type:                       Clarification Requested
Severity:                   Editorial
Priority:                   normal
Status:                     New
Name:                       steffen 
Organization:                
User Reference:              
Section:                    find 
Page Number:                2946 
Line Number:                98444 ff. 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2024-11-07 21:34 UTC
Last Modified:              2024-11-14 17:03 UTC
====================================================================== 
Summary:                    find: clarify "less safe" statement
====================================================================== 

---------------------------------------------------------------------- 
 (0006956) geoffclare (manager) - 2024-11-14 17:03
 https://austingroupbugs.net/view.php?id=1872#c6956 
---------------------------------------------------------------------- 
This was discussed when those words were added to Issue 8.  There is a
danger in allowing partial input records to be treated as complete.  As an
example, if find is used to generate a list of directories to be
recursively removed and a partial pathname is accepted by xargs, it could
result in the accidental removal of a much larger subtree in a filesystem
than was intended.  The current standard allows this behavior due to
existing practice, but we hope to be able to disallow processing of partial
input in a future revision of the standard.

At page 3600 line 123176 section xargs, change:<blockquote>If the standard
input is not empty and does not end with a null byte, <i>xargs</i> should
ignore the trailing non-null bytes (as this can signal incomplete data) but
may use them as the last argument passed to
utility.</blockquote>to:<blockquote>If the standard input is not empty and
does not end with a null byte, <i>xargs</i> should treat the trailing
non-null bytes (which can signal incomplete data) as an error but may use
them as the last argument passed to <i>utility</i>.</blockquote>

Add to RATIONALE after page 3605 line 123412:<blockquote>When the <b>-0</b>
option is not specified, if the standard input is not empty and does not
end with a <newline>, then the input is not a text file, and therefore the
behavior is undefined. However, it is recommended that <i>xargs</i>
diagnoses the trailing non-<newline> characters (for consistency with the
recommendation for <b>-0</b> and trailing non-null bytes).</blockquote> 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2024-11-07 21:34 steffen        New Issue                                    
2024-11-07 21:34 steffen        Name                      => steffen         
2024-11-07 21:34 steffen        Section                   => find            
2024-11-07 21:34 steffen        Page Number               => 2946            
2024-11-07 21:34 steffen        Line Number               => 98444 ff.       
2024-11-07 21:38 steffen        Note Added: 0006951                          
2024-11-08 01:40 steffen        Note Added: 0006952                          
2024-11-08 01:42 steffen        Note Edited: 0006952                         
2024-11-08 08:31 stephane       Note Added: 0006953                          
2024-11-12 09:48 geoffclare     Note Added: 0006954                          
2024-11-13 18:19 steffen        Note Edited: 0006952                         
2024-11-14 17:03 geoffclare     Note Added: 0006956                          
======================================================================


  • [1003.1(2024... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Steffen Nurpmeso via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to