Minutes of the 20th January 2022 Teleconference Austin-1191 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 22nd January 2022 Attendees: Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Don Cragun, IEEE PASC OR Andrew Josey, The Open Group Geoff Clare, The Open Group Eric Blake, Red Hat, The Open Group OR Rob Landley Mark Ziegast, SHware Systems Dev. Tom Thompson, IEEE Apologies Eric Ackermann, HPI, University of Potsdam * General news This was a call dedicated to General bugs. We briefly discussed the PASC P&P. Andrew, Joe Gwinn, and Don need to respond to Tom at IEEE. * Outstanding actions None. * Current Business Bug 1505: Make doesn't seem to specify unset macro expansion behaviour Accepted as Marked https://austingroupbugs.net/view.php?id=1505 This item is tagged for Issue 8 All page and line numbers are for Issue 8 draft 2.1. On page 2943 line 98732 change: that completely matches the [op]%[os] pattern on the left hand side to: that completely matches, in a case-sensitive manner, the [op]%[os] pattern on the left hand side On page 2944 line 98750 change: If the original value of the variable named by string1 is an empty string, the final result shall be an empty string. Matching shall be case-sensitive. to: In all forms of macro expansion, if the value of the macro named by string1 is an empty string, or if the macro named by string1 does not exist, the final result shall be an empty string. Note:It is not safe to assume that a macro which has not intentionally been set to a specific value will not exist. See APPLICATION USAGE for more information. On page 2951 after line 99038, add the following new paragraphs to APPLICATION USAGE: Although make expands macros that do not exist to an empty string, makefile authors should be aware that it is not safe to assume that a macro which has not intentionally been set to a specific value will expand to an empty string for everyone who uses the makefile. There are two reasons for this: 1. When another user executes make, they might happen to have an environment variable of the same name (which they have set for some unrelated purpose) with a non-empty value. 2. A different implementation of make (or a later version of the same implementation) might have a non-empty value for the macro in its default set. This is one aspect of a more general problem, which is that any macro that is not one for which this standard requires a default value, and is not explicitly set either in the makefile or on the make command line, can have an unexpected value (or unexpectedly not exist) when the makefile is used by a different user or with a different make implementation. For this reason, it is recommended that makefile authors do not design makefile schemes in which values for non-standard macros are obtained from the user's environment variables. Safer methods of allowing users to configure macro values include: * Setting the macros to default values in a make include file where the user can edit the values. * Executing make from one or more wrapper scripts which set macro values on the command line (and which do not obtain those values from environment variables). Makefile authors who follow this recommendation may wish to check for any macros they have overlooked by using a make implementation that provides, as an extension, a command-line option that causes make to report attempts to expand (or append to) macros that do not exist. Users of makefiles written by others can also benefit from use of such an option to detect the opposite problem (where the author had a macro being set from an environment variable but the user does not have the variable set). This can avoid misbehaviors that would otherwise be hard to debug, such as a file-processing utility reading from standard input because it was not given any pathnames to process. Makefile authors who choose not to follow the recommendation can minimize the risk of misbehavior by ensuring all non-standard macros have names that begin with a suitable project-specific prefix. Use of the -e option is strongly discouraged, as it makes the problem discussed above even more likely by introducing the possibility of unexpected values occurring even for macros set in the makefile. If a specific macro needs a value from the environment to override a value set in the makefile, it is safer to set just that macro on the command line, using for example make MYPROJ_FOO="$MYPROJ_FOO". Alternatively, the makefile can be modified to use the ?= assignment operator for that macro. On page 2956 after line 99259 add two new paragraphs to RATIONALE: Implementations are permitted to include any macro of their choosing in the default set. However, they are encouraged to keep such additions to a minimum in order to reduce the risk of name clashes with user macros. Implementations are encouraged to provide, as an extension, a command-line option that causes make to report attempts to expand (or append to) macros that do not exist. See APPLICATION USAGE for the intended use cases of such an option. On page 2960 after line 99479 add a new paragraph to FUTURE DIRECTIONS: A future version of this standard may add a command-line option that causes make to report attempts to expand (or append to) macros that do not exist. Bug 1527: cd requires the impossible on standard output Accepted as Marked https://austingroupbugs.net/bug_view_page.php?bug_id=1527 This item is tagged for TC3-2008 In lines 83024-83025 change the words an absolute pathname of the new working directory shall be written to and the absolute pathname of the new working directory can be determined, that pathname shall be written Between lines 83026 and 83027 insert a new paragraph If an absolute pathname of the new current working directory cannot be determined, it is unspecified whether nothing is written to the standard output or the value of curpath used in step 10, followed by a , is written to the standard output. In line 83027 change the word: Otherwise to: If a non-empty directory name from CDPATH is not used, and the directory argument is not '-' After line 83048 add to APPLICATION USAGE: If an absolute pathname of the new current working directory cannot be determined, and a non-empty directory name from CDPATH is used, cd may write a pathname to standard output that is not an absolute pathname. Bug 1528: mailx: document "sh(1) -c --" has to be used instead of "sh -c" Accepted https://austingroupbugs.net/bug_view_page.php?bug_id=1528 This item is tagged for TC3-2008 Bug 1529: ex: follow-up to issue #1440 OPEN https://austingroupbugs.net/bug_view_page.php?bug_id=1529 We will continue on this item next time. Next Steps ---------- The next calls are on: Mon 2022-01-24 (gettext) Thu 2022-01-27 (general bugs) The calls are for 90 minutes Calls are anchored on US time. (8am Pacific) Please check the calendar invites for dial in details. Bugs are at: https://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/20xx-mm-dd (For write access this uses The Open Group single sign on, for those individuals with gitlab.opengroup.org accounts. Please contact Andrew if you need to be setup)