A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1561 ====================================================================== Reported By: calestyo Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1561 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Christoph Anton Mitterer Organization: User Reference: Section: various Page Number: N/A Line Number: N/A Final Accepted Text: ====================================================================== Date Submitted: 2022-02-01 00:10 UTC Last Modified: 2022-04-15 23:38 UTC ====================================================================== Summary: clarify what kind of data shell variables need to be able to hold ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0001560 clarify wording of command substitution related to 0001562 printf utility: clarify what is (byte) ... related to 0001564 clariy on what (character/byte) strings... ======================================================================
---------------------------------------------------------------------- (0005807) calestyo (reporter) - 2022-04-15 23:38 https://www.austingroupbugs.net/view.php?id=1561#c5807 ---------------------------------------------------------------------- Re: https://www.austingroupbugs.net/view.php?id=1561#c5795 Some of the experts which all have undoubtedly much more knowledge than me should probably rather review that... nevertheless... > Since field splitting is performed on the results of > (unquoted) parameter expansions, it is also affected > by this issue, but the fix is included in my suggested > changes for bug 0001560 so is not repeated here. I assume with fix you mean the introduction of "bytes"/"byte sequence" there? > Parameters can contain arbitrary byte sequences I assume that this wording implies in the language of the standard, that conforming shells *MUST* support that, right? > Shell variables shall be initialized only from > environment variables that have valid names. What exactly is the intention of this? Cause if it's that a shell must not "take over" e.g. '+=whatAWeirdVariable', then this was (at least indirectly) already clear before, by variables being parameters and these, as per 2.5, having names (in the sense of 3.235 Name). If your intention is however to forbid that environment variables with invalid names must not be "taken over" by transcribing their invalid name into something valid (e.g. replacing any invalid chars with '__<unicode code point>__' - which would of course be prone to collisions) than I think this wording is too unclear/indirect and it should rather be something like: "Environment variable that don't have valid names must not be made shell variables, not even by transcribing the invalid names or similar means." However some shells may e.g. wish to provide such invalidly named env vars in a special shell var (like an associative array)... so that should perhaps be allowed? At least, I personally think, that the current sentence is a bit vague what it exactly means. > The shell shall process their values as characters > only when performing operations that are described > in this standard in terms of characters. That one is quite nice! > ... for character substring processing. May I suggest to rather directly write something like: "The following four varieties of parameter expansion provide for substring processing, with each of them requiring the value to be a character string." Especially the "substring" makes it IMO a tiny bit vague... like in: foo="${binaryString}." cmdSubstWithTrailingNL=${foo%.} One could claim: "well,... the '.' is a substring of $foo... and only that is processed as character and matched... so fine" Further, this basically assume the current proposal of https://www.austingroupbugs.net/view.php?id=1562 ... i.e. that pattern matching notation would always be on character strings. However, on the mailing list, Harald van Dijk offered to look more deeply into that matter, ... So may I kindly request that you defer voting on this particular part of the above changes, until Harald had a chance to do so? > However, the shell may initialize parameters that do not have valid names from such environment variables. What's that intended for? To allow positional/special parameters to be initialised from the environment variable? Issue History Date Modified Username Field Change ====================================================================== 2022-02-01 00:10 calestyo New Issue 2022-02-01 00:10 calestyo Name => Christoph Anton Mitterer 2022-02-01 00:10 calestyo Section => various 2022-02-01 00:10 calestyo Page Number => N/A 2022-02-01 00:10 calestyo Line Number => N/A 2022-02-01 19:33 mirabilos Note Added: 0005645 2022-02-01 19:44 calestyo Note Added: 0005647 2022-02-01 20:52 chet_ramey Note Added: 0005649 2022-02-01 23:07 kre Note Added: 0005650 2022-02-02 15:15 chet_ramey Note Added: 0005652 2022-02-02 16:39 calestyo Note Added: 0005653 2022-02-02 18:44 kre Note Added: 0005654 2022-02-06 11:18 mirabilos Note Added: 0005662 2022-02-06 18:18 chet_ramey Note Added: 0005665 2022-02-06 23:17 kre Note Added: 0005666 2022-02-08 15:14 calestyo Note Added: 0005668 2022-02-09 01:58 kre Note Added: 0005669 2022-04-07 16:29 geoffclare Relationship added related to 0001560 2022-04-07 16:30 geoffclare Relationship added related to 0001562 2022-04-07 16:30 geoffclare Relationship added related to 0001564 2022-04-11 13:52 geoffclare Note Added: 0005795 2022-04-15 23:38 calestyo Note Added: 0005807 ======================================================================
