A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1778 ====================================================================== Reported By: kre Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1778 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section: XCU 3/read Page Number: 3291-3294 Line Number: 111869-111878, 111961-111963, 11946, 11979-11980 Final Accepted Text: ====================================================================== Date Submitted: 2023-10-02 13:58 UTC Last Modified: 2023-10-04 14:42 UTC ====================================================================== Summary: The read utility needs field splitting updates/corrections )and a little more) ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001649 Field splitting is woefully under speci... ======================================================================
---------------------------------------------------------------------- (0006513) kre (reporter) - 2023-10-04 14:42 https://www.austingroupbugs.net/view.php?id=1778#c6513 ---------------------------------------------------------------------- Re https://www.austingroupbugs.net/view.php?id=1778#c6512 .. OK, but that still leaves open the question of what it means to "process those operands" in the case of read (1). For utilities like ls, cp, mkdir, ... where there is a basic operation to perform, and then that operation is performed upon each operand in turn. Since read's operation isn't (really) to process each operand in turn (that is, it is required to read the input up to the end delimiter before doing anything else, not to read one field at a time for each var named) - that simply setting up the vars named ready to be assigned to, once data is available, is all the processing that is required. Then the actual order in which the assignments get made would not be specified. And yes, I know that's something of a stretch, which is why I did not write the text to allow that, https://www.austingroupbugs.net/view.php?id=1778#c6500 requires that the fields be assigned in order, and probably should be updated to ensure that all variable names (args on the command line) for which no data is available do get assigned the empty string, even if the same var name was previously the object of an assignment. But there's another more specific (related) requirement in https://www.austingroupbugs.net/view.php?id=1778#c6500 than what is in the current text - my new version requires that the field splitting complete before any variable assignments are made, whereas while the current text suggests that, it isn't actually required. This makes a difference if a variable assigned to can alter the way the field splitting works, for which the obvious example is IFS - but (some of) the locale variables can have an effect as well, as they can affect how IFS is interpreted. What's more, when we do this we have some wild behaviours amongst shells, a majority (all ash derived shells, yash, ksh93) behave as described in https://www.austingroupbugs.net/view.php?id=1778#c6500 but several (older ksh's, bosh, and zsh) assign the variables as each field is produced, such that altering IFS alters how the next field is delimited, and bash seems to simply disable (further) field splitting if IFS is altered, and the remainder of the input is assigned to the next variable. Or at least that's the general behaviour, things get more strange if IFS white space is assigned to IFS during the process. Given: IFS=: ; printf %s\\n "$input" | read -r IFS var rest then with input=',:abc:def,ghi' I see as the final values of IFS var and rest IFS=[,] var=[abc] rest=[def,ghi] (shells where vars are assigned late) IFS=[,] var=[abc:def,ghi] rest=[] (bash) IFS=[,] var=[abc:def] rest=[ghi] (shells which do field by field assignments) With input=':abc:def,ghi' only the final set changes (and in a consistent way) IFS=[] var=[abc:def,ghi] rest=[] With input=' : abc:def,ghi ' IFS=[ ] var=[ abc] rest=[def,ghi ] (shells which field split first) IFS=[ ] var=[ abc:def,ghi ] rest=[] (bash) Both of those are consistent with the first set of results, just with different input data IFS=[ ] var=[abc:def,ghi] rest=[] IFS=[ ] var=[] rest=[abc:def,ghi] IFS=[ ] var=[] rest=[ abc:def,ghi] from the shells which do immediate updates to vars when fields are split (but only the first of those makes any real sense to me at all). What we ought to do about this I am unwilling to say - keep https://www.austingroupbugs.net/view.php?id=1778#c6500 as it is, or make it unspecified whether vars are assigned immediately each output field is produced by field splitting, either of those would be possible. Mandating immediate assignment would be unacceptable I believe. Issue History Date Modified Username Field Change ====================================================================== 2023-10-02 13:58 kre New Issue 2023-10-02 13:58 kre Name => Robert Elz 2023-10-02 13:58 kre Section => XCU 3/read 2023-10-02 13:58 kre Page Number => 3291-3294 2023-10-02 13:58 kre Line Number => 111869-111878, 111961-111963, 11946, 11979-11980 2023-10-02 14:00 kre Note Added: 0006500 2023-10-02 14:02 kre Note Edited: 0006500 2023-10-02 14:20 kre Note Added: 0006502 2023-10-02 14:22 kre Note Edited: 0006502 2023-10-02 14:24 kre Note Edited: 0006502 2023-10-02 14:30 kre Note Added: 0006503 2023-10-02 14:33 kre Note Edited: 0006502 2023-10-02 14:34 kre Note Edited: 0006502 2023-10-02 14:44 kre Note Edited: 0006500 2023-10-02 16:18 geoffclare Project 1003.1(2013)/Issue7+TC1 => Issue 8 drafts 2023-10-02 16:19 geoffclare version => Draft 3 2023-10-02 16:20 geoffclare Note Added: 0006507 2023-10-02 16:21 geoffclare Relationship added related to 0001649 2023-10-03 09:23 geoffclare Note Added: 0006509 2023-10-03 11:59 kre Note Added: 0006510 2023-10-03 12:11 kre Note Added: 0006511 2023-10-03 13:42 geoffclare Note Added: 0006512 2023-10-04 14:42 kre Note Added: 0006513 ======================================================================
