A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1422 
====================================================================== 
Reported By:                joerg
Assigned To:                
====================================================================== 
Project:                    Issue 8 drafts
Issue ID:                   1422
Category:                   Shell and Utilities
Type:                       Error
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       Jörg Schilling 
Organization:                
User Reference:              
Section:                     
Page Number:                2894-2895 
Line Number:                97277-97282 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2020-11-18 13:49 UTC
Last Modified:              2021-03-05 19:18 UTC
====================================================================== 
Summary:                    The current definition for the += assingment is in
conflict  with existing behavior of make and unpredictable/error-prone
====================================================================== 

---------------------------------------------------------------------- 
 (0005260) psmith (developer) - 2021-03-05 19:18
 https://www.austingroupbugs.net/view.php?id=1422#c5260 
---------------------------------------------------------------------- 
The behavior of += with respect to = (delayed) assignment is as you
describe it: it appends the new text to the end of the existing text
without any expansion and expansion happens when the variable is used.

Regarding "macro :sh=command", that is not part of the POSIX standard so
you can decide how it works with respect to += as you like, I suppose.

Regarding the ::= assignment: this is intended to work (as I understand it)
the same way that ":=" works in GNU make.  That is, when the variable
assignment is made the RHS is expanded immediately, and after that the
value is treated as a static string and is no longer expanded when the
variable is used.  If a "+=" is made to a variable that was created with
"::=", the RHS is expanded first, then the result of that expansion is
appended to the variable.

I think it's misleading to consider "::=" to be related to Sun's ":sh=";
they are different and unrelated to each other.  The goal of introducing a
new operator like "::=" is exactly because the behavior we want there is
not like existing make behavior; so it is not an inconsistency that they
are different.

Allowing the value of a ":=" assignment to be re-expanded again when the
variable is used would be quite confusing.  For example:

    foo := $$hello

    all: ; @echo '$(foo)'

would print 'ello', instead of the desired '$hello'. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2020-11-18 13:49 joerg          New Issue                                    
2020-11-18 13:49 joerg          Name                      => Jörg Schilling 
2020-11-18 13:49 joerg          Page Number               => 2894-2895       
2020-11-18 13:49 joerg          Line Number               => 97277-97282     
2021-03-05 16:11 geoffclare     Note Added: 0005257                          
2021-03-05 17:07 psmith         Note Added: 0005258                          
2021-03-05 17:10 psmith         Note Edited: 0005258                         
2021-03-05 17:11 psmith         Note Edited: 0005258                         
2021-03-05 17:17 psmith         Note Edited: 0005258                         
2021-03-05 18:30 joerg          Note Added: 0005259                          
2021-03-05 19:18 psmith         Note Added: 0005260                          
======================================================================


  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to