A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1649 ====================================================================== Reported By: kre Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1649 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Robert Elz Organization: User Reference: Section: XCU 2.6.5 Page Number: 2476 Line Number: 80478 - 80504 Final Accepted Text: ====================================================================== Date Submitted: 2023-03-31 01:55 UTC Last Modified: 2023-09-07 16:40 UTC ====================================================================== Summary: Field splitting is woefully under specified, and in places, simply wrong ======================================================================
---------------------------------------------------------------------- (0006472) geoffclare (manager) - 2023-09-07 16:40 https://austingroupbugs.net/view.php?id=1649#c6472 ---------------------------------------------------------------------- The problem description includes mention of character encoding and LC_CTYPE, but the proposed wording in https://austingroupbugs.net/view.php?id=1649#c6460 does not address this. Instead it describes everything in terms of characters, effectively reversing the changes made by bug https://austingroupbugs.net/view.php?id=1560. Without those changes it is unclear how field splitting works on command substitutions (or pathname expansions) where the expansion results contain byte sequences that do not form characters. Changes along the lines of those in bug 1560 need to be made to the proposed new wording. The character encoding issue could perhaps be partially addressed by extending the requirement that <period>, <slash>, <newline>, and <carriage-return> are invariant across all locales (see XBD 6.1) to include at least <space> and <tab> as well. How the handling of IFS characters with non-invariant encodings should be specified (i.e. "which LC_CTYPE") will depend on what shells currently do. (Please note that after posting this I will be unavailable for three weeks, so will not be able to respond to any follow up comments in a timely manner.) Issue History Date Modified Username Field Change ====================================================================== 2023-03-31 01:55 kre New Issue 2023-03-31 01:55 kre File Added: ifs 2023-03-31 01:55 kre Name => Robert Elz 2023-03-31 01:55 kre Section => XCU 2.6.5 2023-03-31 01:55 kre Page Number => 2476 2023-03-31 01:55 kre Line Number => 80478 - 80504 2023-07-31 16:13 Don Cragun Note Added: 0006412 2023-09-07 14:14 kre Note Added: 0006459 2023-09-07 14:15 kre Note Added: 0006460 2023-09-07 14:30 kre Note Added: 0006462 2023-09-07 14:32 kre Note Added: 0006463 2023-09-07 14:41 kre Note Deleted: 0006463 2023-09-07 14:43 kre Note Edited: 0006462 2023-09-07 14:45 kre Note Added: 0006464 2023-09-07 14:54 kre Note Added: 0006465 2023-09-07 15:01 kre Note Added: 0006466 2023-09-07 15:03 kre Note Added: 0006467 2023-09-07 15:06 kre File Added: IFS-test 2023-09-07 15:07 kre File Added: POSIX-bug-1649-impl.sh 2023-09-07 15:09 kre File Added: Expected-Results 2023-09-07 15:15 kre Note Added: 0006468 2023-09-07 15:21 kre Note Added: 0006469 2023-09-07 15:22 kre Note Edited: 0006469 2023-09-07 16:12 kre Note Added: 0006471 2023-09-07 16:40 geoffclare Note Added: 0006472 ======================================================================
