A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1607 ====================================================================== Reported By: nmeum Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1607 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Sören Tempel Organization: User Reference: Section: ed Page Number: 2691 Line Number: 87825 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2022-09-26 12:22 UTC Last Modified: 2022-09-27 08:59 UTC ====================================================================== Summary: Operator associativity for address chain operator is not specified ======================================================================
---------------------------------------------------------------------- (0005979) nmeum (reporter) - 2022-09-27 08:59 https://austingroupbugs.net/view.php?id=1607#c5979 ---------------------------------------------------------------------- Thank you for your detailed comments. > That goes back to the first sentence of my Note: 0005975 .. it probably is not stated, and should be. But in that case we both agree that the specification currently does not describe how an address chain like "7,5," should be evaluated, that is the point of this clarification request. I think the discussion here clearly demonstrates that "reverse-engineering" the evaluation algorithm from examples such as "3;/foo/;+2p" or "7,5," can obviously lead to wrong results. All I am asking for is a clarification of this algorithm in a normative section. Grouping separators from the right was just me trying to make sense of the example chains in the rationale section. > I suspect this might be one of those "everyone just knows" kinds of things, no-one who really knows ed can even imagine address chains being evaluated any other way. This is not the only time this (apparently) has led to sloppy wording. I would just propose adding an additional sentence to the paragraph in line number 87370 to describe the address chain evaluation algorithm that "everyone just knows" but isn't stated in the specification currently. > But it is very dangerous to ever claim something is not in the standard [...] The "Addresses in ed" section (line number 87317), or more specifically, the paragraph in 87370 - 87373 (where the "," and ";" separators are introduced) is where I would have expected the algorithm to be described. As far as I can tell, it is not described in this section. For the purpose of clarification, it makes sense to describe the algorithm in this section. Issue History Date Modified Username Field Change ====================================================================== 2022-09-26 12:22 nmeum New Issue 2022-09-26 12:22 nmeum Name => Sören Tempel 2022-09-26 12:22 nmeum Section => ed 2022-09-26 12:22 nmeum Page Number => 2691 2022-09-26 12:22 nmeum Line Number => 87825 2022-09-26 14:01 kre Note Added: 0005975 2022-09-26 16:54 nmeum Note Added: 0005976 2022-09-26 19:30 kre Note Added: 0005977 2022-09-26 19:46 kre Note Edited: 0005975 2022-09-26 19:55 kre Note Added: 0005978 2022-09-27 08:59 nmeum Note Added: 0005979 ======================================================================
