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-26 19:30 UTC ====================================================================== Summary: Operator associativity for address chain operator is not specified ======================================================================
---------------------------------------------------------------------- (0005977) kre (reporter) - 2022-09-26 19:30 https://austingroupbugs.net/view.php?id=1607#c5977 ---------------------------------------------------------------------- Re https://austingroupbugs.net/view.php?id=1607#c5976 OK, I see now how you got the "1,$" but that's not the way things work. but isn't this a question of applying the omission rules? Eventually, yes. Since 7,5 is already a valid address there are no omission rules to apply. It is actually 2 addresses, but yes, that's correct otherwise. As such, you would then expand "," to "1,$" No, that rule only applies when there is no address before (or after) the ',', but that's not the case here, here there is an address before the ',', "5" (and another before that, but that one is irrelevant now). What we have is "5," not a bare "," and in that case line 87379 applies. When you do: 7,5, -> (7,5), -> (7,5)(1,$) you have managed to make 4 addresses (7 5 1 and $) with only 2 separators, and that makes no sense at all. There are 3 addresses, you cannot invent a new one. You wouldn't do that kind of transformation with arithmetic, you don't do it here either -- consider 2*3*4 - treated as (2*3)*4 you cannot make that into (2*3)(0*4) or even (2*3)(1*4) it just makes no sense. We would end up with (6)(0) (or (6)(4)) - so should the answer be either 60 or 64? I hope not. Why would "(7,5)" be "5" and "5,"? No, not a typo, 7,5 is two addresses, when we proceed to the next addr, only the 2nd of those means anything, hence "5" the separator is "," so we are now evaluating "5," and line 87379 applies. where is this stated in the spec? That goes back to the first sentence of my https://austingroupbugs.net/view.php?id=1607#c5975 .. it probably is not stated, and should be. But it is very dangerous to ever claim something is not in the standard, one would need to know every word of all of it, to be sure of that, and I don't think anyone claims that ability. This doesn't mean that sections can't be improved, even if that is not strictly necessary. 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. Perhaps the best demonstration of what is intended is this sentence, also from the Rationale (and so, as you surmised, not normative, not really a part of the standard - though it is possible to use to resolve ambiguities). >From lines 87815-8: For example, the command "3;/foo/;+2p" will display the first line after line 3 that contains the pattern foo, plus the next two lines. Note that the address "3;" must still be evaluated before being discarded, because the search origin for the "/foo/" command depends on this. ["/foo/" is not a command, but an address, and that ought be fixed, but that isn't the point here.] If you attempt to apply your method to this address chain you will absolutely not get the desired result. But if you do simple left to right address evaluation, where the ',', or in this case ';' (do note that an address chain can use both ',' and ';' as separators) marks the division between the addresses (only when not in a pattern of course) the result is obvious. First address, "3" that's a simple case, line 3. Separator is ';' so set '.' to 3. Second address "/foo/" search forward from '.' looking for the r.e. (in this case, just a string) "foo"). Let's assume that is found in line 12. Next separator is ';' so set '.' to 12. Third address "+2" which means ".+2" or 14. So the evaluated addr chain is 3 12 14 The 'p' command takes only (max of) 2 addresses, so the 3 is ignored at this stage, and we print lines 12 13 and 14 (ie: the first line after line 3 containing "foo" and the two following lines, just as the text says will happen). ed really is a very simply beast, if there is an easy way to explain how something might work, and a complex one, the easy one will be correct every time. 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 ======================================================================
