A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1560 ====================================================================== Reported By: calestyo Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1560 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Christoph Anton Mitterer Organization: User Reference: Section: 2.6.3 Command Substitution Page Number: 2323 Line Number: 74944 Final Accepted Text: ====================================================================== Date Submitted: 2022-01-31 23:30 UTC Last Modified: 2022-04-15 00:41 UTC ====================================================================== Summary: clarify wording of command substitution ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001561 clarify what kind of data shell variabl... ======================================================================
---------------------------------------------------------------------- (0005802) calestyo (reporter) - 2022-04-15 00:41 https://www.austingroupbugs.net/view.php?id=1560#c5802 ---------------------------------------------------------------------- AFAIU, this involves now three types of changes: 1) The first one, which improves on the wording of trailing newlines. => seems good to me. 2) "comprising each character of the IFS" and similar "The shell shall treat the byte sequence comprising each character of the IFS as a delimiter" It took me a bit to understand what's meant. I would reword this, especially the "each" is a bit strange here, I think. AFAIU, you want to say, that any byte sequence in a word, that equals one of the characters in IFS is to be taken as a split point. So isn't that *any* character... not *each* character? What about: "The shell shall treat a byte sequence forming any character of the characters in the IFS value as a delimiter" - "comprise" doesn't quite fit, IMO - replaced "the byte sequence" with "a...", cause "the" would be a concrete one, but there may be several (as there are several characters in IFS) - aligned the wording with what you did in the change a bit below. The same in: "The term ``IFS white space'' is used to mean any sequence (zero or more instances) of the byte sequences that comprise white-space characters in the IFS value (for example, if IFS contains <space>/<comma>/<tab>, any sequence of bytes that have the encoded values of <space> and <tab> characters is considered IFS white space)." rather something like: "The term ``IFS white space'' is used to mean any sequence (zero or more instances) of the byte sequences that form any of the white-space characters in the IFS value..." Perhaps also instead of "is used to mean" just "means". 3) You introduce bytes/byte sequences vs. characters. I don't understand why you need that at all? The old wordings didn't really mention the to-be-matched-data (i.e. the processed words, which may be bytes) at all... just what's matched with (i.e. the characters of IFS),... which kinda delegated the question of with what the characters are matched with to other places. Is this because, regardless of the lexical locale (i.e. the one in which the script/command is parsed, all the words are considered bytes (other than NUL), e.g. coming from parameter expansions/command substitutions, etc. (which all may be bytes) and you want to emphasise this? I'm not against that change (of "type" (3))... I just wonder why and whether it's really needed at this point (or just complicates reading)... or whether it's already clear that words that undergo field splitting may be bytes. Perhaps it would be better to generally mention that somewhere in the field splitting chapter? I.e. something like: "The words that undergo field splitting may be any byte (except NUL) and for the purpose of field splitting are matched against the characters of IFS". However, as said, I wouldn't oppose that change, if you think it makes things clearer... I'd approve. => But there is one thing that's IMO lost on the way: The old: " any sequence of <space>, <tab>, or <newline> characters at the beginning or end of the input shall be ignored and any sequence of those characters within the input shall delimit a field" "sequence of those characters" indicated that a sequence of 1-n IFS characters were still regarded as one single field splitter. With the new: "ignored and any sequence of such bytes" that's IMO a bit lost... sequence of bytes is rather considered like ONE "multi-byte" character. You don't have that problem with the 4th change, where you explicitly say: "any sequence (zero or more instances) of the byte sequences that comprise white-space characters" But these difference between the two (the latter, where you specifically point it out vs. the former where not)... makes it IMO even more to be interpreted like as if the first case would be different. Issue History Date Modified Username Field Change ====================================================================== 2022-01-31 23:30 calestyo New Issue 2022-01-31 23:30 calestyo Name => Christoph Anton Mitterer 2022-01-31 23:30 calestyo Section => 2.6.3 Command Substitution 2022-01-31 23:30 calestyo Page Number => 2323 2022-01-31 23:30 calestyo Line Number => 74944 2022-04-07 16:29 geoffclare Relationship added related to 0001561 2022-04-11 13:50 geoffclare Note Added: 0005794 2022-04-15 00:41 calestyo Note Added: 0005802 ======================================================================
