Minutes of the 5th August 2021 Teleconference Austin-1153 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 6th August 2021 Attendees: Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Don Cragun, IEEE PASC OR Andrew Josey, The Open Group Eric Blake, Red Hat, The Open Group OR Mark Ziegast, SHware Systems Dev. Joerg Schilling Eric Ackermann, HPI, University of Potsdam Geoff Clare, The Open Group Tom Thompson, IEEE Apologies: Richard Hansen * General news This was a call dedicated to general bugs. * Outstanding actions (Please note that this section has been flushed to shorten the minutes - to locate the previous set of outstanding actions, look to the minutes from 13th June 2019 and earlier) Bug 1254: "asynchronous list" description uses "command" instead of "AND-OR list" OPEN https://austingroupbugs.net/view.php?id=1254 Action: Joerg to investigate how his shell behaves. Bug 713 - Nick to raise with the C committee. This item raised in Austin/1129 and submitted to the C committee in May 2021. * Current Business Bug 1491: $0 ≠ ${00} ? Accepted as Marked https://www.austingroupbugs.net/view.php?id=1491 This item is tagged for TC3-2008. On page 2312 change lines 74465-74466 from: A positional parameter is a parameter denoted by the decimal value represented by one or more digits, other than the single digit 0. The digits denoting the positional parameters shall always be interpreted as a decimal value, even if there is a leading zero. When a positional parameter with more than one digit is specified, the application shall enclose the digits in braces (see Section 2.6.2). Positional parameters are initially assigned... to: A positional parameter is a parameter denoted by a decimal representation of a positive integer. The digits denoting the positional parameters shall always be interpreted as a decimal value, even if there is a leading zero. When a positional parameter with more than one digit is specified, the application shall enclose the digits in braces (see Section 2.6.2). Examples: * "$8", "${8}", "${08}", "${008}", etc. all expand to the value of the eighth positional parameter. * "${10}" expands to the value of the tenth positional parameter. * "$10" expands to the value of the first positional parameter followed by the character '0'. Note: 0 is a special parameter, not a positional parameter, and therefore the results of expanding ${00} are unspecified. Positional parameters are initially assigned... On page 2318 change lines 74733-74736 from: If the parameter is not enclosed in braces, and is a name, the expansion shall use the longest valid name (see XBD Section 3.207), whether or not the variable represented by that name exists. Otherwise, the parameter is a single-character symbol, and behavior is unspecified if that character is neither a digit nor one of the special parameters (see Section 2.5.2). to: For a parameter that is not enclosed in braces: * If the parameter is a name, the expansion shall use the longest valid name (see XBD Section 3.207), whether or not the variable denoted by that name exists. * Otherwise, the parameter is a single-character symbol, and behavior is unspecified if that character is neither a digit nor one of the special parameters (see Section 2.5.2). Bug 1471: Add an orthogonal interface for immediate macro expansion definitions to make OPEN https://www.austingroupbugs.net/view.php?id=1471 We continued this item. Detailed notes in the etherpad. Joerg had completed his action from last time to gather input from the BSD developers. quote: On Mon, Aug 02, 2021 at 06:42:14PM +0200, Joerg Schilling wrote: > Do you believe that POSIX should include a method to control whether $$ is > expanded with := or not? I don't know the history of this (or at least, not without going and raking it up) but I'd say that $$ should never be expanded except at the final output stage. The purpose of $$ is to produce $ in the output, not cater to monstrosities like $$$$$$$$(VAR) that depend on knowing exactly how many and which eval stages are going to be applied to your text. Because evaluation/expansion in make traditionally repeats until it converges (as opposed to sh where it happens exactly once and you need to play games with eval to do complicated things) it's a bad idea to encourage or even allow constructions whose meaning depends on how many eval passes happen. We've had various bad experiences along these lines and have had to fix bmake to avoid them. I'm also kind of skeptical, since the issue is lazy vs. eager evaluation, that more varieties of assignment operator are going to do anything to improve the situation. -end quote- We plan to continue this item on the next Thursday call. The next call will be a gettext call. The gettext draft in the etherpad is at https://posix.rhansen.org/p/gettext_draft Next Steps ---------- The next calls are on: Mon 2021-08-09 Gettext This call will be for 90 minutes. Thu 2020-08-12 (D2 & general bugs) This call will be 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)