A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1920 
====================================================================== 
Reported By:                stephane
Assigned To:                
====================================================================== 
Project:                    1003.1(2013)/Issue7+TC1
Issue ID:                   1920
Category:                   Shell and Utilities
Type:                       Omission
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       Stephane Chazelas 
Organization:                
User Reference:              
Section:                    read utility, stdin section 
Page Number:                3321 
Line Number:                112915 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2025-04-21 07:16 UTC
Last Modified:              2025-04-23 16:57 UTC
====================================================================== 
Summary:                    read -d '' on invalid text without -r and IFS=
====================================================================== 

---------------------------------------------------------------------- 
 (0007145) stephane (reporter) - 2025-04-23 16:57
 https://www.austingroupbugs.net/view.php?id=1920#c7145 
---------------------------------------------------------------------- 
Re: https://www.austingroupbugs.net/view.php?id=1920#c7143

> Once you use -d '', you can't assume the fields are "text", and the lack of
> "-r" presumes that the input is text and that we know what its encoding is.
> The *obvious* solution would be to allow implementations  to silently
> enable '-r' whenever -d is passed an empty string.

While implying -r, and maybe skipping IFS-splitting may make sense for -d ''
(when reading NUL-delimited records), -d was not initially intended to read
NUL-delimited records.

Actually, read -d '' didn't work in ksh93 where that option came from over 30
years ago. AFAIK, it's bash that first extended it so read -d '' meant read
until the next 0 byte (more or less as an accident of implementation, as it's
implemented in C with its NUL-delimited strings, and it was taking the first
byte of such strings).

read -d has been used and is still being used to read text records with
different delimiters like  IFS=' ' read -d , word to read comma-separated words,
trimming leading and trailing spaces. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2025-04-21 07:16 stephane       New Issue                                    
2025-04-21 07:30 stephane       Note Added: 0007139                          
2025-04-21 07:38 stephane       Note Edited: 0007139                         
2025-04-22 14:46 geoffclare     Note Added: 0007140                          
2025-04-22 15:20 hvd            Note Added: 0007141                          
2025-04-22 18:45 chet_ramey     Note Added: 0007142                          
2025-04-23 14:59 dwheeler       Note Added: 0007143                          
2025-04-23 16:47 stephane       Note Added: 0007144                          
2025-04-23 16:57 stephane       Note Added: 0007145                          
======================================================================


  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group

Reply via email to